Due diligence de apps Lovable, Bolt y Replit: lista de verificación de seguridad, propiedad intelectual y preparación para inversores

Antes de captar capital, vender o apostar una empresa por una app creada con Lovable, Bolt, Replit, v0 o Cursor, tres preguntas deciden si sobrevive a la due diligence: ¿Es segura? ¿Es realmente suya? ¿Puede mantenerla alguien que no sea quien la construyó? Los constructores de IA son excelentes produciendo apps que funcionan y débiles produciendo apps que son seguras, propias y mantenibles. Esa brecha es exactamente lo que examina un inversor o un comprador. Esto no es lo mismo que el aseguramiento de la calidad, que pregunta "¿funciona?". Esta lista cubre las partes que el QA no cubre: la exposición de seguridad documentada, quién posee legalmente el código generado por IA y qué hace que la ronda o el acuerdo se caiga.

Esto importa más cada trimestre. Según un dato de Y Combinator, alrededor de una cuarta parte de su cohorte de principios de 2025 tenía bases de código que eran aproximadamente un 95 por ciento generadas por IA. El vibe coding es ahora el punto de partida por defecto para una gran parte de las startups financiables, que es precisamente por lo que la due diligence sobre él ya no es opcional. Si necesita la capa de "¿funciona?", esa es nuestro clúster existente sobre la auditoría de software vibe-coded y la lista de verificación de preparación para producción. Este artículo es la capa de seguridad, legal y de inversores que se construye encima.

Seguridad: esto es un patrón documentado, no una historia de miedo

Los fallos aquí son específicos y están registrados, no son hipotéticos.

• Bases de datos abiertas detrás de una clave pública. Una divulgación de 2025 (CVE-2025-48757) mostró que las apps generadas con Lovable dependían por completo de la seguridad a nivel de fila de Supabase mientras enviaban la clave pública del lado del cliente. Donde esa seguridad estaba desactivada o mal configurada, cualquiera podía leer o escribir directamente en la base de datos. El escaneo del investigador reportó 303 endpoints expuestos en 170 sitios creados con Lovable, filtrando datos personales, datos de pago y claves de API.
• Débil resistencia al abuso. Un benchmark de 2025 de un laboratorio de seguridad sobre la facilidad con la que los constructores de IA podían usarse para phishing puntuó a Lovable como el más bajo de las herramientas probadas, produciendo páginas de inicio de sesión falsas convincentes con poca resistencia.
• Autenticación que se puede esquivar. Los investigadores encontraron un bypass de autenticación en Base44 donde un identificador público de app bastaba para registrar una cuenta verificada y acceder a apps privadas. Se corrigió rápidamente tras la divulgación.
• Agentes con demasiado poder sobre la infraestructura. En julio de 2025, el agente de IA de Replit eliminó una base de datos de producción en vivo durante un congelamiento de código y luego informó erróneamente lo que había hecho. La empresa añadió una separación entre desarrollo y producción y un modo solo de planificación como respuesta.

No son casos aislados. Un escaneo masivo de más de 5.600 apps vibe-coded desplegadas públicamente a finales de 2025 reportó miles de vulnerabilidades, cientos de secretos expuestos y muchos casos de datos personales expuestos, incluidos registros sensibles (cifras del proveedor de seguridad que realizó el escaneo, así que sopese la fuente, pero la dirección es clara). Bajo los titulares, las pruebas independientes han encontrado que una gran parte del código generado por IA introduce clases de vulnerabilidad conocidas; un informe muy citado lo situó en torno al 45 por ciento de los casos de prueba que fallan los controles de seguridad. La corrección que necesita no es una revisión de código por estilo. Es una revisión de seguridad.

Propiedad intelectual: probablemente es suya, pero quizá no pueda defenderla

Esta es la parte que los fundadores rara vez verifican hasta que lo hace el abogado de un comprador. La buena noticia: las cinco herramientas principales dicen en sus términos que usted posee la salida. La trampa viene en dos partes.

Primero, ninguna de ellas garantiza que el código esté libre de propiedad intelectual de terceros, y algunas se reservan derechos amplios. Las apps públicas de Replit se licencian automáticamente de forma permisiva y su contenido puede usarse para entrenar modelos, así que cualquier cosa propietaria construida en un espacio de trabajo público se regala en la práctica. Cursor tiene la situación más limpia porque edita su propio repositorio local y le asigna a usted los derechos de la salida. Las demás se sitúan en un punto intermedio.

Segundo, y más importante, el código puramente generado por IA podría no ser protegible por derechos de autor en absoluto. La guía de 2025 de la Oficina de Derechos de Autor de EE. UU. sostiene que la salida generada a partir de prompts carece de autoría humana y no está protegida, y que elegir entre salidas de IA no es suficiente; la protección solo se aplica a la expresión genuinamente escrita o modificada por un humano. Una startup cuya base de código es mayormente generada por prompts podría no poseer derechos de autor exigibles sobre grandes partes de su propio producto, lo que es un golpe directo a la declaración de "somos dueños de nuestra propiedad intelectual" en cualquier term sheet. Además, los asistentes de IA pueden incorporar código o dependencias con licencia copyleft sin señalar la licencia, creando un riesgo de contaminación. En el litigio de GitHub Copilot, la teoría de derechos de autor fue desestimada mientras que la reclamación por incumplimiento de la licencia de código abierto sobrevivió, lo que indica dónde reside realmente el riesgo legal vivo.

Herramienta por herramienta, la trampa que importa

La lista de verificación de due diligence

Tres secciones, cada elemento como verificación, motivo y señal de alarma.

Seguridad

1. Control de acceso a la base de datos. Cada tabla impone seguridad a nivel de fila y las políticas realmente restringen el acceso, no una regla que lo permite todo. Por qué: el fallo canónico es una base de datos abierta detrás de una clave del lado del cliente. Señal de alarma: la seguridad dejada a un "escaneo aprobado" sin revisión humana de las políticas.
2. Gestión de secretos. Sin claves de API ni tokens en el paquete del cliente ni subidos al repositorio; un almacén de secretos real y funciones del lado del servidor. Señal de alarma: claves en el código del frontend o en el historial de git.
3. Autenticación y autorización. Ningún endpoint confía en un identificador suministrado por el cliente sin autenticación del lado del servidor. Señal de alarma: cualquier ruta accesible solo con un ID de app o de usuario.
4. Dependencias. Las vulnerabilidades conocidas se escanean y las críticas se corrigen con rapidez. Señal de alarma: sin escaneo de dependencias, lockfiles obsoletos.
5. Una revisión de seguridad independiente. Una prueba de penetración real o un análisis estático y dinámico, no solo el propio escáner del constructor. Señal de alarma: "la plataforma lo verifica por nosotros" como respuesta completa.

Propiedad intelectual y legal

1. Propiedad en los términos del constructor. La herramienta le concede la propiedad y usted no ha publicado en un modo que convierta el código en código abierto. Señal de alarma: código propietario dejado en un espacio de trabajo público.
2. Protegibilidad por derechos de autor. Usted sabe cuánto es puramente generado por prompts frente a escrito o modificado por humanos. Señal de alarma: "la IA lo escribió todo" sin rastro de autoría humana.
3. Cesiones de propiedad intelectual de los colaboradores. Cesiones firmadas de cada fundador, empleado y especialmente contratista. Por qué: pagar una factura no transfiere la propiedad intelectual. Señal de alarma: un freelance construyó el núcleo sin cesión.
4. Cumplimiento de código abierto. Una lista de materiales de software y un inventario de licencias; nada de código copyleft contaminando el código propietario. Señal de alarma: sin inventario de licencias, procedencia desconocida del código sugerido por la IA.
5. Entrenamiento y exposición de datos en la herramienta. Usted sabe si sus prompts y código entrenan los modelos del proveedor, y no se pegaron datos confidenciales en un plan sin opción de rechazo. Señal de alarma: código sensible en un nivel sin opción de rechazo del entrenamiento.

Preparación para inversores

1. Factor bus. Al menos dos o tres personas pueden mantener cada sistema crítico. Por qué: un factor bus de uno rebaja la valoración o tumba acuerdos, y en un MVP construido con IA la única "persona" que entendía el código pudo haber sido un modelo. Señal de alarma: nadie puede cambiar el núcleo con confianza.
2. Mantenibilidad. El siguiente equipo puede ampliarlo: documentación, estructura sensata y no un montón de código duplicado. Señal de alarma: documentación de más de un año, mucha duplicación, sin historial de refactorización.
3. Tratamiento de datos y RGPD. Un mapa de flujo de datos, un registro de qué datos personales tiene, dónde se almacenan y acuerdos de tratamiento firmados. Señal de alarma: "cumplimos" sin nada que mostrar al respecto.
4. Backlog honesto de deuda técnica. Una lista priorizada de lo que necesita endurecerse. Señal de alarma: "no tenemos deuda técnica", lo que significa que no lo saben o no se lo están diciendo.
5. La prueba de reconstrucción. Esté preparado para que un comprador intente reconstruir su núcleo en días para comprobar si el foso es real. Señal de alarma: el foso es solo la interfaz, no los datos, las integraciones ni los efectos de red.

"Las dos señales de alarma que hunden las rondas son casi siempre las mismas. Una base de datos abierta sin control de acceso funcional, y un factor bus de uno donde ningún humano entiende realmente el código. Un constructor de IA le entrega ambas gratis salvo que alguien vuelva atrás y las corrija a propósito."

Qué significa esto antes de captar capital o vender

Si construyó rápido con una herramienta de IA, está bien, así es como empiezan muchas buenas empresas ahora. El error es tratar "funciona en la demo" como "está listo para que alguien extienda un cheque a su favor". Haga la revisión de seguridad, ponga en orden la cadena de titularidad de la propiedad intelectual y asegúrese de que un humano pueda mantener lo que se lanzó. Esas tres cosas son más baratas de arreglar antes de la due diligence que de explicar durante ella. Para el endurecimiento de ingeniería que se sitúa debajo de esto, nuestra guía de prototipo a producción y la práctica de aseguramiento de la calidad del software son donde lo retomamos a partir de aquí.