Estás a punto de comprar una participación en un activo que no has inspeccionado. La auditoría de código es la inspección — pero solo si se acota para responder preguntas de inversión y no de ingeniería.
La auditoría de código previa a la inversión se sitúa dentro de la due diligence técnica más amplia y tiene un cometido más estrecho: establecer qué existe realmente, si la propiedad está limpia y si puede sostener el plan que se financia.
Mal acotada, produce una lista de quejas de estilo. Bien acotada, produce dos o tres hallazgos que cambian el acuerdo.
Qué accesos solicitar
Pídelos antes de firmar el term sheet. La resistencia en esta fase ya es informativa por sí sola.
- Acceso de lectura a todos los repositorios — incluida la infraestructura como código y los scripts de despliegue, donde suele verse el estado real de las cosas
- Historial completo de commits, no una instantánea aplastada: el historial revela quién construyó realmente el sistema y a qué velocidad avanza
- Un recorrido por la arquitectura con el ingeniero que la construyó, de una a dos horas
- Acceso al gestor de incidencias y, si existen, a los registros de incidentes
- La lista de servicios de terceros de los que depende el producto
Las ocho preguntas que la auditoría debe responder
- ¿El código que existe coincide con lo descrito en el pitch? (El demoware y las integraciones que en realidad son procesos manuales son habituales.)
- ¿Quién lo escribió, y esas personas siguen ahí?
- ¿La propiedad intelectual está limpia — contratistas con cesión, sin código copiado sin licencia, sin contaminación de licencia por dependencias GPL en un producto propietario?
- ¿Qué se rompe primero bajo el plan de crecimiento, y cuánto cuesta mover ese techo?
- ¿Están aislados los datos de clientes entre tenants, y se aplica la autorización en el servidor?
- Para todo lo financiero: ¿existe un libro mayor inmutable, y es idempotente cada ruta del dinero?
- ¿Puede el equipo desplegar con seguridad — automatización, rollback, monitorización?
- ¿Cuánto del producto es genuinamente suyo frente a una capa fina sobre proveedores que pueden cambiar precios o desaparecer?
Hallazgos que justifican una cláusula
| Hallazgo | Consecuencia típica |
|---|---|
| Núcleo construido por contratistas sin cesión de PI | Cerrar antes de transferir — remedio legal, no técnico |
| Sin libro mayor en una empresa que mueve dinero | Presupuesto de remediación financiado en la ronda; posible tramificación |
| Exposición de datos entre tenants | Corrección como condición de cierre |
| Dependencia crítica de proveedor sin alternativa | Riesgo de concentración divulgado; a veces un covenant |
| Bus factor de uno en el sistema central | Paquete de retención o seguro de persona clave |
| Sin despliegue automatizado | Costeado en el plan post-cierre |
Lo que no merece tu atención
Los auditores que facturan por hallazgos te entregarán una lista larga. La mayor parte no importa para una decisión de inversión:
- Preferencias de framework o lenguaje — toda elección tiene críticos
- Estilo de código y formato inconsistentes
- Porcentaje global bajo de cobertura de test, cuando las rutas de dinero y auth están cubiertas
- Dependencias desactualizadas sin vulnerabilidad alcanzable
- Documentación ausente — realmente común, rara vez decisiva, barata de arreglar
Si el informe de auditoría no se puede resumir en tres frases a tu comité de inversión, se acotó como ejercicio de ingeniería y no de inversión.
Cómo es un buen entregable
- Un resumen de una página en lenguaje de negocio, con una posición de riesgo global clara
- Hallazgos ordenados por consecuencia, cada uno con evidencia que el equipo del objetivo pueda verificar
- Coste de remediación en semanas-ingeniero, para que se convierta en dinero
- Un plan técnico recomendado a 90 días tras el cierre
- Una lista explícita de lo que NO se examinó, para que nadie asuma una cobertura que no existió
Especificar las evidencias que se contratan
El comprador debe poder seguir un hallazgo hasta su fuente y entender el coste de actuar.
- Identificar repositorio, commit, entorno y fecha de revisión.
- Pedir ejemplos, recorridos afectados y supuestos de esfuerzo.
- Exigir exclusiones y opción de verificación posterior.
Preguntas frecuentes
¿Cuánto tarda una auditoría de código previa a la inversión?
De tres a diez días laborables para la mayoría de objetivos seed y Series A. Fintech, healthtech o bases de código inusualmente grandes tardan más. Pasadas dos semanas normalmente compras detalle en vez de decisiones.
¿Sabrá la startup que la estamos auditando?
Sí — una auditoría con sentido requiere acceso al repositorio y tiempo de ingenieros, así que es un proceso cooperativo. Los objetivos serios lo esperan y suelen estar cómodos; una resistencia inusual merece anotarse por sí sola.
¿Se puede auditar sin acceso al código fuente?
Solo superficialmente. Sin el repositorio puedes evaluar el producto en funcionamiento, la postura pública de seguridad y las señales del equipo, pero no la limpieza de la PI, la arquitectura real o la mantenibilidad — que suelen ser los hallazgos que importan.
¿Y si la auditoría encuentra problemas graves?
Esa es una auditoría exitosa, y rara vez acaba con el acuerdo. La mayoría de hallazgos se convierten en presupuesto de remediación, condición de cierre, financiación por tramos o ajuste de valoración. El fallo real es descubrir los mismos problemas en el mes seis, cuando cuestan mucho más.
¿Debe recibir el auditor una copia de producción?
No por defecto. Prioriza datos sintéticos o anonimizados adecuadamente y acceso limitado. Amplíalo solo para una pregunta concreta que no pueda resolverse de otro modo.
¿Necesitas una auditoría antes de transferir?
Hallazgos ordenados por consecuencia de negocio, remediación valorada en semanas-ingeniero, entregado en menos de dos semanas.
Para seguir leyendo
Due diligence técnica para inversores: la guía completa
La due diligence técnica no es una revisión de código. Es la respuesta a una pregunta: ¿cuánto costará llevar esta tecnología hasta donde la tesis de inversión la necesita?
Auditoría técnica de MVP: qué revisamos en las primeras 48 horas
La mayoría de las auditorías de MVP producen un documento. Una útil produce decisiones: qué está ardiendo, qué puede esperar y cuánto cuesta arreglarlo.