Due diligence técnica antes de levantar capital

La due diligence técnica es la revisión que un inversor hace de tu tecnología antes de cerrar una ronda: quién es dueño del código, qué licencias arrastran tus dependencias, cómo tratas los datos personales y qué registros puedes probar. Lo que hunde una ronda es casi siempre la deuda técnica sin documentar.

La distinción importa. Ningún inversor espera encontrar una arquitectura impecable en una compañía de dos años. Lo que espera es que el equipo fundador sepa exactamente dónde están los problemas, cuánto cuesta arreglarlos y en qué orden piensa hacerlo. Una lista honesta de deuda técnica genera confianza. Un descubrimiento inesperado en la última semana del proceso genera una renegociación de valoración, una cláusula de retención o, con más frecuencia de la que se cuenta, una retirada silenciosa.

¿Qué es la due diligence técnica y en qué se diferencia de la legal y la financiera?

La due diligence técnica es una auditoría independiente del activo tecnológico y de la organización que lo produce. Se ocupa de cuatro preguntas: si la tecnología existe tal y como se describe, si la empresa es su titular legítima, si puede escalarse sin reescribirla y si su operación crea riesgos legales o de seguridad que el inversor heredará.

No sustituye a la due diligence legal ni a la financiera; se solapa con ambas en los bordes. La titularidad del código es simultáneamente una cuestión técnica y contractual. El tratamiento de datos personales es a la vez una decisión de arquitectura y una obligación regulatoria. Ese solapamiento es precisamente donde se concentran los hallazgos graves, porque suele ser tierra de nadie entre el equipo técnico y el asesor jurídico.

Quien la ejecuta varía: un socio con perfil técnico, un CTO en residencia del fondo, una firma externa especializada o una combinación. En rondas semilla puede resolverse en dos sesiones y un cuestionario. A partir de serie A es habitual un proceso de tres a seis semanas con acceso a repositorios, entornos y personas.

¿Qué mira un inversor, punto por punto?

Área	Qué se pide	Señal de alarma
Titularidad del código	Contratos de fundadores, empleados y freelancers con cesión expresa de derechos	Colaboradores externos sin cláusula de cesión; código traído de un empleador anterior
Dependencias y licencias	Inventario de componentes con identificador de licencia y modo de enlace	Ausencia de inventario; licencias copyleft fuertes en un producto propietario
Datos personales	Registro de actividades de tratamiento, bases jurídicas, encargados, transferencias internacionales	No existe registro; datos de producción replicados en entornos de desarrollo
Seguridad	Gestión de accesos, cifrado, gestión de secretos, respuesta a incidentes	Credenciales en el repositorio; cuentas compartidas; sin registro de accesos
Infraestructura	Reproducibilidad del despliegue, copias de seguridad probadas, dependencia de proveedores	Servidores configurados a mano; copias que nunca se han restaurado
Arquitectura	Diagramas actualizados, límites de escalado conocidos, decisiones documentadas	Diagramas que no coinciden con la realidad del sistema
Equipo	Concentración de conocimiento, documentación de onboarding	Una sola persona entiende el núcleo del producto
Uso de IA	Proveedores, tratamiento de datos, supervisión humana, trazabilidad de decisiones	Modelos de terceros procesando datos de clientes sin contrato ni control

Esta tabla no es un examen que haya que aprobar entero. Es el mapa de las preguntas que llegarán. Tener respuesta escrita para cada fila, aunque la respuesta sea «esto todavía no está resuelto y este es el plan», cambia por completo el tono de la conversación.

¿Qué hunde una ronda de verdad?

Cinco hallazgos concentran la mayoría de los problemas graves.

1. El código no es de la empresa. Ocurre cuando hay desarrollo hecho por autónomos sin cláusula expresa de cesión de derechos de explotación, cuando un fundador aportó trabajo previo sin formalizar la aportación, o cuando existe sospecha de código creado bajo relación laboral con un tercero. En muchos ordenamientos, encargar y pagar un trabajo no transfiere automáticamente todos los derechos: hace falta un pacto escrito. Este es el único hallazgo que puede convertir el activo principal de la compañía en un litigio.

2. Licencias incompatibles con el modelo de negocio. Cada dependencia impone condiciones. Las licencias permisivas exigen poco más que atribución; las de copyleft fuerte pueden obligar a publicar el código derivado. La lista de identificadores normalizados está en la lista de licencias SPDX y el catálogo de licencias aprobadas se publica en la Open Source Initiative. Un inventario de componentes con su identificador de licencia y su modo de enlace es un documento de dos horas de trabajo que evita una semana de pánico.

3. Datos personales sin base jurídica documentada. El artículo 30 del Reglamento (UE) 2016/679 obliga a mantener un registro de las actividades de tratamiento. No es un documento decorativo: es la primera prueba de que la empresa sabe qué datos tiene, para qué, durante cuánto tiempo y con quién los comparte. Su ausencia le dice al inversor que nadie ha hecho ese ejercicio nunca.

4. Ausencia de registros. Sin registros de acceso, sin trazabilidad de despliegues y sin histórico de decisiones, la empresa no puede demostrar nada sobre su propio pasado: ni que un incidente no ocurrió, ni que un cambio fue autorizado, ni que un dato se borró cuando dijo que se borró. La ausencia de registro no es neutral; en una disputa juega en contra de quien tenía la obligación de registrar.

5. Secretos en el repositorio. Claves de API, credenciales de base de datos y certificados en el histórico de versiones. Aunque se hayan borrado del código actual, siguen en el histórico. Es el hallazgo más fácil de encontrar con herramientas automáticas y el que más rápido erosiona la credibilidad del equipo.

¿Qué significa «deuda técnica documentada» y por qué pesa más que la deuda misma?

Deuda técnica documentada es un registro vivo donde cada compromiso conocido aparece con cuatro datos: qué se decidió, por qué se decidió así en su momento, qué impacto tiene hoy y qué haría falta para resolverlo.

Un inversor no penaliza los atajos: sabe que una startup que no toma atajos no llega a la ronda. Lo que penaliza es la incertidumbre. Una lista de treinta elementos con coste estimado es un plan. Ninguna lista es un agujero negro, y los agujeros negros se valoran mal.

El mismo principio aplica a los incidentes. Un incidente de seguridad gestionado, documentado y con lecciones aplicadas es un activo de madurez. Un incidente que aparece en la revisión y no estaba en la conversación previa es un problema de confianza, que es mucho peor que un problema técnico.

¿Cómo se prueba que el documento del data room es el que se firmó?

Un proceso de inversión mueve decenas de documentos entre partes que no se conocen: acuerdos con clientes, cesiones de derechos, políticas internas, informes técnicos. Meses o años después, en una disputa sobre declaraciones y garantías, la pregunta será si la versión que se entregó es la que ahora se exhibe.

Esa pregunta no se responde con la fecha del archivo ni con la copia de seguridad, porque quien custodia el sistema puede modificarlo. Se responde con una huella criptográfica del documento y un sello temporal verificable de forma independiente. Es exactamente el mismo mecanismo que sostiene la cadena de custodia de evidencia digital y la conservación de expedientes contractuales, aplicado aquí a un data room.

¿Qué se puede arreglar en noventa días y qué no?

Plazo	Qué es realista	Qué no lo es
0 a 30 días	Inventario de dependencias y licencias; rotación de secretos y limpieza del histórico; registro de actividades de tratamiento; inventario de accesos	Rediseñar la arquitectura
30 a 60 días	Contratos de cesión de derechos firmados o regularizados; gestión centralizada de secretos; copias de seguridad probadas con restauración real; diagramas actualizados	Acumular meses de evidencia operativa que no existe
60 a 90 días	Registro de deuda técnica con coste estimado; procedimiento de respuesta a incidentes escrito y ensayado; documentación de onboarding que reduzca la concentración de conocimiento	Obtener un informe de auditor independiente

La regla práctica: todo lo que consista en documentar, inventariar y formalizar cabe en noventa días. Todo lo que consista en acumular historial —evidencia de que un control ha funcionado durante meses— no cabe, porque el tiempo no se comprime. Por eso conviene empezar antes de necesitarlo.

¿En qué se diferencia esto de prepararse para SOC 2?

Son dos ejercicios distintos que se confunden a menudo. La due diligence es una fotografía completa y puntual: cubre titularidad, arquitectura, equipo, datos y seguridad, y termina cuando cierra la ronda. Un marco como SOC 2 es estrecho y continuo: cubre un conjunto acotado de criterios y exige demostrar que los controles operaron durante un período.

Tener el marco ayuda en la revisión, pero no la sustituye: ningún informe de auditoría dice quién es el titular del código. Y prepararse para la revisión no equivale a estar listo para una auditoría. Si tu horizonte incluye clientes empresariales además de inversores, conviene entender por dónde se empieza de verdad con SOC 2 antes de contratar nada.

Qué hacer ahora

1. Monta el inventario de dependencias con licencia esta semana. Es el hallazgo más común y el más barato de cerrar.
2. Revisa los contratos de todo el que haya tocado el código, incluidos los colaboradores de hace tres años. Busca cesión expresa de derechos de explotación, por escrito.
3. Escribe el registro de actividades de tratamiento aunque sea en una hoja de cálculo. Un registro imperfecto vale más que ninguno.
4. Rota los secretos y limpia el histórico del repositorio. Asume que todo lo que estuvo alguna vez en el repositorio está comprometido.
5. Abre el registro de deuda técnica y llévalo a las reuniones de inversores tú mismo, antes de que lo encuentren.
6. Sella los documentos críticos del data room con huella y fecha verificable antes de compartirlos.

Si quieres que la revisión la haga alguien de tu lado antes de que la haga el fondo, en Compliance preparamos el expediente técnico completo, y en Startups y fintech trabajamos con el calendario real de una ronda. El estado de cada marco que aplicamos internamente, con su etiqueta honesta, está publicado en /trust.

Cuéntanos en qué fase estás y qué te han pedido: hablemos.