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 necesitan pruebas: ¿Es segura? ¿Tiene los derechos necesarios? ¿Puede mantenerla alguien distinto de quien la construyó? Una demo funcional no responde esas preguntas. Esta lista cubre controles de seguridad, la posición contractual y de derechos de autor del código asistido por IA, y la preparación operativa. Es una guía general de due diligence, no asesoramiento jurídico.

Las herramientas cambian rápido, pero las preguntas de due diligence no. Para la capa de "¿funciona?", empiece por nuestra auditoría de software vibe-coded y la lista de preparación para producción. Este artículo añade las capas de seguridad, legal e inversora.

Seguridad: verifique controles, no marcas

La documentación oficial vigente respalda cuatro comprobaciones concretas:

• Permisos y políticas de base de datos. Supabase indica que una clave publicable o la antigua clave anon está diseñada para exponerse, pero solo es segura con RLS y permisos mínimos bien configurados. Las claves secretas y service_role nunca deben enviarse al cliente. Pruebe operaciones permitidas y denegadas. Consulte la guía de seguridad y la guía de RLS.
• Los escaneos tienen límites. Lovable ejecuta un escaneo básico antes de publicar y ofrece otros más profundos, pero el básico se centra en patrones comunes. No sustituye pruebas de autorización específicas. Consulte la descripción de seguridad de Lovable.
• Exposición de proyectos públicos. Lovable divulgó que regresiones entre el 3 de febrero y el 20 de abril de 2026 permitieron que un usuario autenticado con el enlace a un proyecto público accediera a su código e historial de chat. Afirma que los proyectos privados y Lovable Cloud no se vieron afectados, y que corrigió el fallo y convirtió los proyectos públicos en privados. Consulte el informe de Lovable.
• Acceso del agente a producción. Replit confirmó en 2025 que Agent eliminó datos de la base de una app antes de la separación actual entre desarrollo y producción. Replit afirma que hoy Agent está restringido a desarrollo y que existe rollback. Consulte su respuesta y arquitectura de snapshots.

La conclusión práctica es más estrecha que cualquier estadística llamativa: inspeccione el sistema desplegado. Pruebe autorización, políticas de base de datos, secretos, dependencias, recuperación y separación entre desarrollo y producción.

Propiedad intelectual: la titularidad contractual es solo una capa

Los términos actuales suelen asignar derechos sobre la salida al cliente, pero difieren en proyectos públicos, entrenamiento, garantías y derechos de terceros. Lea los términos aplicables a su cuenta y archive una copia fechada.

Lovable asigna datos del cliente y salida al cliente entre las partes, sujeto a derechos de terceros, pero no garantiza singularidad ni ausencia de infracción. Puede usar datos para entrenamiento hasta que el cliente rechace el uso futuro. Replit conserva los derechos del usuario, pero licencia bajo MIT el contenido de Public Apps y puede usarlo para entrenamiento. Bolt afirma que el código creado es suyo y comercialmente utilizable. Vercel trata prompts y salidas como contenido del cliente, con controles de entrenamiento según plan y configuración. Cursor cede sus derechos sobre Suggestions al cliente, sin garantizar singularidad. Consulte Lovable, Replit, Bolt, Vercel y Cursor.

Los derechos de autor dependen de la jurisdicción y del aporte humano. El informe de 2025 de la Oficina de Derechos de Autor de EE. UU. dice que los prompts por sí solos generalmente no aportan suficiente control humano, pero la expresión humana, la disposición creativa y las modificaciones creativas pueden estar protegidas. Usar IA no deja desprotegida toda la obra. Documente decisiones humanas y revise procedencia y licencias.

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. Acuerdos con colaboradores. Asesoría jurídica ha revisado los acuerdos de fundadores, empleados y contratistas según la ley aplicable. Señal de alarma: un contratista creó funciones centrales y el contrato no aclara la propiedad intelectual.
4. Cumplimiento de código abierto. Mantenga SBOM e inventario de licencias y cumpla las obligaciones de cada licencia. Señal de alarma: procedencia desconocida del código generado o de las dependencias.
5. Entrenamiento y exposición de datos. Registre plan, privacidad, subencargados y retención vigentes al enviar material confidencial. Señal de alarma: código sensible enviado sin confirmar los controles aplicables.

Preparación para inversores

1. Factor bus. Más de una persona puede operar y cambiar cada sistema crítico. Señal de alarma: nadie salvo quien lo construyó 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. Portabilidad y diferenciación. Demuestre que exportar, compilar, desplegar, restaurar y operar no depende de la sesión de una sola persona. Señal de alarma: no existe una ruta probada de exportación o recuperación.

"Una demo demuestra que una ruta funcionó una vez. La due diligence pregunta quién puede acceder a cada ruta, quién puede recuperar los datos, qué derechos posee la empresa y quién mantendrá el sistema cuando se vaya quien lo construyó."

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í.