Due diligence tecnológico: lo que tu pitch dejó fuera

La demo salió bien y el term sheet ya está sobre la mesa. Entonces el equipo de due diligence del otro lado pide acceso a tu repositorio, cada componente open source con su licencia, tu último informe de pentest, tu registro de incidentes y una respuesta directa: ¿quién opera producción si mañana renuncian dos ingenieros?

Eso es el due diligence tecnológico: una revisión de tu código, licencias, seguridad, arquitectura y equipo antes de que el dinero cambie de manos. Sus hallazgos no tienen que hundir la operación para costarte caro. Cambian las condiciones: un precio más bajo, dinero retenido en escrow, una indemnización que firmas tú, correcciones obligatorias antes del cierre. Nuestra lectura: haz tú primero la misma revisión y la historia la controlas tú.

¿Qué revisa de verdad un due diligence tecnológico?

En una ronda semilla, el inversionista quizá haga unas cuantas preguntas; un comprador puede pagarle a un tercero para que escanee tu código. Las preguntas se agrupan en cinco áreas: licencias, vulnerabilidades, brechas heredadas, arquitectura y personas. Cualquiera puede terminar como condición del contrato.

En un white paper de M&A de marzo de 2026, Black Duck, que vende auditorías de código para adquisiciones, dice que los problemas de licencias suelen terminar en protecciones para el comprador, correcciones previas al cierre, escrows, rebajas de precio o retrasos.

¿Tus licencias open source están en conflicto?

El informe OSSRA 2026 de Black Duck (Open Source Security and Risk Analysis) cubre 947 bases de código comerciales que su equipo auditó entre noviembre de 2024 y octubre de 2025, para M&A, cumplimiento regulatorio y evaluaciones internas de riesgo. El 68% tenía conflictos de licencias, frente al 56% un año antes. Por operación, el white paper de M&A encontró conflictos de licencias en el 94% de las auditadas. Son datos de un proveedor sobre empresas intensivas en software, con más de 1,000 componentes open source por base de código en promedio: marcan la tendencia, no tus probabilidades.

Revisa antes:

• Genera un SBOM (software bill of materials, el inventario de componentes) desde tu build, en un formato legible por máquina como CycloneDX o SPDX.
• Corre un escaneo de licencias. Marca el código sin licencia y las licencias copyleft como GPL o AGPL, que según cómo distribuyas tu producto pueden obligarte a publicar tu código fuente.
• Busca el código que no pasó por tu gestor de paquetes: librerías copiadas, snippets pegados, sugerencias de IA.
• Si vendes funciones de IA: qué modelos, con qué licencias y con qué datos se entrenaron o ajustaron, incluido si tus clientes lo autorizaron.

Con el SBOM ya llevas ventaja: según el mismo white paper, a la mayoría de las empresas evaluadas les cuesta producirlo, y cuando lo logran, rara vez es preciso y nunca está completo. En la UE, el SBOM ya está en la ley para los productos de software: el Reglamento de Ciberresiliencia (Cyber Resilience Act), vigente desde el 10 de diciembre de 2024, exige a los fabricantes, a partir del 11 de diciembre de 2027, un SBOM que cubra al menos las dependencias de máximo nivel, es decir, las directas. El software alojado en la nube queda casi siempre fuera, pero un comprador con negocio en Europa lo pedirá igual.

¿Cuántas vulnerabilidades conocidas trae tu producto?

El mismo OSSRA encontró vulnerabilidades conocidas en el 87% de las bases de código, de alto riesgo en el 78% y críticas en el 44%, con un promedio de 581 por base de código, 107% más que un año antes. Un equipo de due diligence no espera cero. Espera que sepas cuántas tienes.

Revisa antes:

• Corre un escaneo de dependencias, corrige los hallazgos críticos y altos, y deja por escrito por qué el resto puede esperar.
• Ten listo tu último informe de pentest con el estado de cada corrección.
• Di con precisión en qué punto está tu SOC 2. Es una atestación, no una certificación: un reporte Type I revisa el diseño de los controles en una fecha; un Type II prueba si funcionaron durante una ventana de observación de meses. Si estás a mitad de esa ventana, dilo. Si todavía no empiezas, prepárate para la auditoría mucho antes de abrir el data room.

¿Qué brechas y obligaciones de datos vienen con la empresa?

Quien compra una empresa compra sus incidentes, incluso los que nadie ha descubierto. Los sistemas de Starwood se vieron comprometidos en 2014, Marriott compró Starwood en 2016 y nadie detectó el ataque hasta septiembre de 2018. En su notificación de sanción de octubre de 2020, la Information Commissioner's Office (ICO) del Reino Unido multó a Marriott con 18.4 millones de libras por fallas posteriores a mayo de 2018, cuando entró en vigor el GDPR. La ICO no se pronunció sobre el due diligence de la compra, pero escribió que revisar las operaciones de datos no tiene límite de tiempo ni se hace una sola vez, y que un due diligence adecuado habría incluido revisar el monitoreo y los logs.

Las condiciones del acuerdo también cambian. En julio de 2016, Yahoo acordó vender su negocio operativo a Verizon; después reveló dos grandes brechas de datos. La enmienda de febrero de 2017 bajó el precio en $350 millones, a cerca de $4,480 millones, repartió ciertas responsabilidades por las brechas y las excluyó al evaluar las condiciones de cierre. Es una megaoperación, no tu referencia, pero el historial de brechas terminó escrito en el contrato.

Revisa antes:

• Un registro escrito de incidentes: fecha, qué se expuso, a quién se notificó, qué cambió.
• Un mapa de datos: qué datos personales tienes, dónde se guardan y qué leyes se aplican (GDPR, LGPD, LOPDP). La guía práctica de GDPR cubre casi todo.
• Acuerdos de procesamiento de datos (DPA) firmados con tus proveedores.
• Logs y monitoreo que de verdad detecten a un intruso, con alertas que alguien lea.

¿Tu arquitectura aguanta el plan de tu pitch deck?

Tu pitch deck promete cuatro veces más clientes en dos años. El due diligence pregunta si el sistema y la factura de la nube resisten ese crecimiento. Casi nada de eso se arregla antes del cierre, así que lleva una estimación honesta de su costo.

Revisa antes:

• El costo de servir a cada cliente, por trimestre. Si sube al crecer, explica por qué.
• El primer componente que se rompe con cuatro veces la carga actual, y cuánto cuesta reemplazarlo.
• Los módulos legacy que nadie quiere tocar, cada uno con un responsable y un plan.
• La calidad del código, sobre todo el escrito con IA: la auditoría de código generado por IA cubre qué revisar.
• Las métricas del deck: ARR, churn y net revenue retention tienen que coincidir con la facturación y el data warehouse. Si generarlas te toma tres días, tus números todavía no cuadran.

¿Qué pasa si se van dos personas?

El riesgo de personas clave no está en el código, así que es fácil saltárselo, y un comprador no puede arreglarlo después del cierre.

Revisa antes:

• Quién puede desplegar a producción y quién controla la cuenta root de la nube, el registrador del dominio y las llaves de firma. Un solo nombre por ítem ya es un hallazgo.
• Acuerdos de cesión de propiedad intelectual firmados por cada empleado y contratista que escribió código. Pide a tu abogado que los revise país por país.
• Runbooks de despliegue, rollback y guardias que alguien fuera del equipo fundador ya haya usado.

¿Cuándo hacer tu propia auditoría tecnológica?

Empezaríamos entre tres y seis meses antes de la ronda o la venta. Los arreglos pequeños toman semanas: cambiar una librería en conflicto, aplicar parches críticos, escribir el registro de incidentes, reunir las cesiones de propiedad intelectual. Los grandes, como una base de datos en su límite, no se resuelven a tiempo, pero puedes explicarlos con un plan y un costo, y un problema explicado se negocia mejor que uno descubierto. Black Duck, que cobra por esas auditorías, le aconseja lo mismo a quien vende su empresa: auditar el código por adelantado.

Resúmelo en un memo breve para el data room: qué encontraste, qué arreglaste, qué falta y cuánto cuesta. Así la llamada de due diligence empieza con tus respuestas y no con sus sorpresas.

Advisory dirige la revisión y escribe la narrativa del data room. Build revisa arquitectura, escala y calidad de código. Secure cubre vulnerabilidades, estado de SOC 2 e historial de brechas. Data cuadra el deck con el data warehouse, y AI cubre el origen de los modelos y sus datos. Cinco prácticas, un solo trabajo. El DGTL Readiness Index califica las ocho en un engagement de Discovery pagado. Conoce nuestra metodología.

Relacionados: La factura del código generado por IA → · SOC 2 sin dolor → · CTO, CMO y CISO fraccional →