La due diligence tecnológica existe para responder a una pregunta: ¿sostiene la tecnología el precio que estás a punto de pagar? Todo lo demás en el informe es evidencia para esa respuesta.
La disciplina se confunde con tres cosas cercanas. No es una auditoría de sistemas, que contrasta controles contra un estándar. No es una evaluación de seguridad, aunque la seguridad sea uno de sus insumos. No es una revisión de código, aunque alguien vaya a leer el código. Es un ejercicio comercial hecho con lente técnica, y el informe que lo olvida termina siendo cuarenta páginas de observaciones ciertas que no cambian nada.
Qué cubre realmente una due diligence tecnológica
Seis áreas concentran casi todo el valor.
La arquitectura y su encaje con el plan. No si la arquitectura es elegante, sino si aguanta el volumen, las geografías, las variantes de producto y el número de clientes que asume la tesis. Un monolito dando servicio a un negocio doméstico estable no es un hallazgo. Ese mismo monolito dentro de una tesis de consolidación que necesita integrar seis adquisiciones en una sola plataforma es la operación entera.
El coste total de propiedad. Coste de operación, licencias, nube y los externos que resultan ser estructurales. Aquí es donde desaparece en silencio el primer año de la mayoría de los planes. El vendedor gestiona el EBITDA de cara al proceso aplazando mantenimiento, dejando caducar contratos de soporte y no cubriendo vacantes. Todo eso es dinero real que hereda el comprador, y nada de ello figura como pasivo.
La deuda técnica, con precio encima. Una lista de quejas del equipo de ingeniería no es un hallazgo. El hallazgo es: este punto cuesta X euros al año dejarlo como está, Y euros arreglarlo, y bloquea estas tres cosas del plan. La deuda que molesta a los ingenieros pero no bloquea nada puede esperar cinco años.
El equipo. Quién tiene de verdad el conocimiento y cuánto se concentra. Una compañía donde solo dos personas saben explicar la lógica de facturación tiene un problema de valoración que ningún ejercicio de documentación va a resolver antes del cierre. Y después: cuánto cuesta ese equipo a precio de mercado actual y no al de la nómina, y si el liderazgo escala al tamaño de organización que implica el plan.
Seguridad, datos y cumplimiento. La parte que se convierte en una indemnidad, una garantía o un ajuste de precio. Dónde están los datos personales, quién tiene acceso, cuál es el historial de incidentes y si las certificaciones que la compañía declara siguen vigentes.
La separabilidad, en carve-outs. Si el activo sale de una matriz: qué se desengancha de verdad, qué necesita un acuerdo de servicios transitorios, cuánto tiene que durar y cuánto va a cobrar cada parte. El coste tecnológico de un carve-out se subestima con más fiabilidad que cualquier otra línea de este trabajo.
Cuándo cambia el resultado una due diligence tecnológica
La mayoría de las veces confirma lo que el equipo de la operación ya sospechaba y la operación sigue adelante. Ese es un resultado razonable, no un honorario tirado: la alternativa es asegurar un parque tecnológico entero sobre la presentación del equipo directivo.
Cambia el resultado en cuatro situaciones reconocibles.
La primera es cuando la tesis depende de una capacidad tecnológica que todavía no existe. El modelo muestra una línea de suscripción arrancando en el año dos; la plataforma no tiene facturación recurrente, ni gestión de derechos, ni medición de consumo. Eso son dieciocho meses y un equipo, no una funcionalidad.
La segunda es la consolidación por compras. El coste de integración es el número que más sistemáticamente se subestima en tecnología dentro del capital riesgo, porque es invisible hasta la segunda adquisición y para entonces la tesis ya está comprometida.
La tercera es una afirmación sobre inteligencia artificial. Es donde más se está fallando ahora mismo. Hay una diferencia grande entre una compañía que posee un modelo, lo mejora con datos propios y tiene un ciclo de realimentación defendible, y una compañía que manda peticiones a la API de un tercero y mete el margen en su bruto. La segunda no vale cero. Vale un múltiplo distinto, y arrastra un riesgo de concentración de proveedor que pertenece al informe.
La cuarta es la concentración en el fundador. Cuando el fundador es además el arquitecto, la única persona que entiende el sistema, y se va en el cierre, el riesgo tecnológico y el riesgo de personas son el mismo riesgo.
Qué cuesta y cuánto dura
| Dimensión | Forma habitual |
|---|---|
| Duración | Ajustada a la ventana de exclusividad, con frecuencia entre dos y cuatro semanas |
| Accesos necesarios | Repositorio de código, facturación de nube, documentación de arquitectura, personal técnico clave, contratos con proveedores relevantes |
| Entregable | Informe corto que empieza por la respuesta, registro de riesgos con precio y plan de cien días |
| Quién lo lee | El equipo de la operación y el comité de inversión, no el CTO |
Los honorarios varían demasiado por alcance y geografía como para que publicar una cifra sirva de algo. La variable que importa más es si el alcance está recortado a las preguntas que todavía pueden cambiar tu decisión. Una due diligence que lo contesta todo y llega después de la oferta vale menos que una que contesta tres cosas a tiempo.
Qué separa un informe útil de uno exhaustivo
Una due diligence tecnológica útil empieza por la respuesta. La primera página dice si la tecnología sostiene la tesis, cuánto costará que la sostenga y qué te haría retirarte. Todo lo que viene después es evidencia.
Pone dinero sobre los hallazgos. «Deuda técnica significativa» no es accionable. «1,4 M€ en dos años para sustituir el sistema de gestión de pedidos, que bloquea la expansión internacional del año dos» sí lo es.
Toma posición. Un asesor que enumera riesgos sin ordenarlos ha devuelto al lector el juicio por el que le estaban pagando.
Y se convierte en plan. Los hallazgos y el plan de cien días deberían ser el mismo documento con dos secciones, porque el equipo que leyó el primero es el que tiene que financiar el segundo.
Preguntas frecuentes
¿La due diligence tecnológica es solo para compañías de software? No. Cualquier negocio donde la tecnología sostenga la operación —retail con cadena de suministro, seguros con sistemas de suscripción de riesgo, logística, salud— tiene riesgo tecnológico relevante para el precio. Las compañías de software necesitan la versión más profunda, pero no son las únicas que la necesitan.
¿Puede hacerla el propio CTO del equipo directivo? Puede aportar el insumo, no la valoración. Un CTO describiendo el parque que ha construido te está dando una defensa, no una due diligence. Su visión entra en el proceso como una fuente más.
¿Qué diferencia hay entre la due diligence de compra y la de venta? La de compra responde a si deberías pagar este precio. La de venta prepara el relato tecnológico antes de abrir el proceso, para que el asesor del comprador no descubra en la segunda semana algo que reabra la negociación. La de venta es más barata y normalmente renta más.
¿Debería el mismo asesor llevar después el trabajo post-cierre? A menudo sí, y la objeción es más débil de lo que parece. Quien encontró el problema ya tiene el contexto y el plan llega antes. Lo que hay que vigilar es al asesor que dimensiona el problema a la medida del encargo de remediación que quiere vender a continuación.