¿Está su app creada con IA lista para producción? Lista de verificación de 20 puntos

Los creadores de apps con IA como Lovable, Bolt, Replit, v0 y Cursor pueden llevarle de una idea a una demo funcional en pocos días. Es un logro real, y también es donde empieza el riesgo. Una demo tiene un solo usuario, datos de prueba y ninguna consecuencia. Una app en producción tiene desconocidos, datos personales, pagos y una reputación que proteger.

Esta lista de verificación cubre las 20 cosas que un ingeniero comprueba antes de que lleguen los usuarios reales. Está escrita para fundadores y responsables de producto, por lo que cada punto explica por qué importa y cómo verificarlo sin leer todo el código. Si no puede responder con seguridad a más de unos pocos puntos, una auditoría técnica de apps con IA le dirá en qué punto se encuentra antes de que lo haga el día del lanzamiento.

Cómo usar esta lista de verificación

Recorra los cinco grupos siguientes y marque cada punto como verificado (usted o alguien lo probó), asumido (el creador probablemente lo hizo) o desconocido. Trate "asumido" igual que "desconocido". Las herramientas de IA producen código que parece completo, y las lagunas suelen estar justo donde nadie probó.

1. Cuentas y acceso

1. El registro, la verificación de correo y el restablecimiento de contraseña funcionan de principio a fin. Cree una cuenta nueva, verifíquela, restablezca la contraseña y luego intente reutilizar el enlace de restablecimiento anterior. Los enlaces de restablecimiento deben caducar y funcionar una sola vez.
2. La autorización se aplica en el servidor, no solo se oculta en la interfaz. Un botón oculto para los usuarios normales no protege nada si la solicitud subyacente sigue funcionando. Inicie sesión como usuario básico y llame directamente a los endpoints de administración. Deben rechazar la solicitud.
3. Los roles se almacenan donde los usuarios no pueden editarlos. En algunos stacks, el usuario puede modificar los metadatos de su perfil. Si "is_admin" reside ahí, cualquier usuario puede ascenderse a sí mismo. Los roles pertenecen a una tabla protegida o a claims controlados por el servidor.
4. El inicio de sesión y otros endpoints sensibles tienen límite de frecuencia. Sin límites, los atacantes pueden probar miles de contraseñas o códigos de un solo uso, y los bots pueden llenar su formulario de registro.
5. Las áreas de administración están protegidas y las cuentas de administrador usan autenticación multifactor. Una sola contraseña de administrador robada no debería bastar para leer los datos de todos los clientes.

2. Datos y privacidad

6. Cada tabla que contiene datos de usuarios tiene reglas de acceso. Con Supabase esto significa Row Level Security. Una tabla sin ella puede ser leída por cualquiera que tenga su clave pública de API. Consulte nuestra guía sobre los siete errores de RLS que cometen las apps creadas con IA.
7. El aislamiento entre inquilinos se demuestra con dos cuentas de prueba. Inicie sesión como el cliente A, copie el ID de un registro y luego intente abrirlo o editarlo como el cliente B. Pruebe también a cambiar los ID en las URL y en las llamadas a la API. Es la prueba más valiosa para cualquier producto multiusuario.
8. Los cambios en la base de datos residen en migraciones con control de versiones. Si el esquema solo existe dentro del panel de un creador, no puede recrearlo, revisarlo ni revertirlo. Recuerde que algunos cambios, como eliminar una columna, no se pueden deshacer sin una copia de seguridad.
9. Las copias de seguridad están activadas y se ha probado una restauración. Una copia de seguridad que nunca ha restaurado es una esperanza, no un plan. Mida cuánto tarda una restauración y anótelo.
10. Usted sabe qué datos personales almacena y cómo eliminarlos. Enumere los campos, dónde residen (incluidos los registros y las herramientas de terceros) y qué ocurre cuando un usuario solicita su eliminación.

3. Pagos y suscripciones

11. Los webhooks de pago verifican la firma y son idempotentes. De lo contrario, cualquiera puede falsificar un mensaje de "pago exitoso", y las entregas duplicadas pueden crear registros duplicados. Más detalles en nuestra guía sobre webhooks y suscripciones de Stripe.
12. El acceso de pago proviene de los eventos de suscripción, no de la página de agradecimiento. La página de éxito es solo una redirección del navegador. La gente cierra pestañas, y cualquiera puede escribir la URL.
13. El modo de prueba y el modo real están totalmente separados, y los fallos se gestionan. Claves, productos y endpoints de webhook independientes. Compruebe qué ocurre ante una renovación fallida, una cancelación, un reembolso y un cambio de plan.

4. Secretos e integraciones

14. Ningún secreto en el bundle del frontend ni en el historial de Git. Todo lo que se envía al navegador es público. Busque en su JavaScript compilado y en su repositorio claves de servicio y tokens de API. Rote cualquier secreto que haya estado expuesto, porque borrar el archivo no borra el historial.
15. Las claves de terceros tienen privilegios mínimos y límites de gasto. Esto importa mucho en las funciones de IA. Una clave de API de un modelo de lenguaje sin restricciones en una app pública puede generar una factura enorme en cuestión de horas. Establezca topes de uso y límites por usuario.
16. Las cargas de archivos y los buckets de almacenamiento están protegidos. Compruebe quién puede leer cada bucket, quién puede subir archivos y si el tipo y el tamaño de archivo están limitados. Los buckets públicos están bien para imágenes públicas y son peligrosos para facturas o documentos de identidad.

5. Despliegue y operaciones

17. Staging y producción están separados. Bases de datos distintas, claves distintas, dominios distintos. Probar con datos de producción es la forma en que los clientes reciben correos de prueba.
18. La monitorización de errores y las alertas de disponibilidad llegan a una persona que actuará. Si lo primero que sabe de una caída es el mensaje de un cliente, falta monitorización.
19. El dominio, HTTPS y la entregabilidad del correo están bien configurados. Eso incluye los registros SPF, DKIM y DMARC, para que los correos de verificación y los recibos no acaben en spam.
20. Existe un plan de reversión y un responsable designado. ¿Quién puede desplegar? ¿Cómo se vuelve a la última versión que funcionaba? ¿Quién está de guardia? Después del lanzamiento, alguien también tiene que aplicar las actualizaciones, que es lo que cubre el mantenimiento mensual de SaaS.

Qué hacer con sus resultados

• Mayoría verificada, algunos desconocidos: pruebe usted mismo los desconocidos esta semana y luego lance con la monitorización activa.
• Varios desconocidos en los grupos 1 a 3: haga una pausa. El acceso, los datos y los pagos son donde los errores se convierten en incidentes. Una revisión enfocada en esas áreas es más barata que una brecha de seguridad o un error de facturación.
• Fallos conocidos: enumérelos con los pasos para reproducirlos. Esa lista es exactamente lo que un ingeniero necesita para dimensionar una solución, y es el punto de partida de nuestro trabajo de reparación y lanzamiento a producción de apps con IA.

Lo que una lista de verificación no puede decirle

Una lista de verificación encuentra categorías conocidas de problemas. No puede juzgar si su arquitectura soportará el crecimiento, si su lógica de negocio tiene fallos sutiles o si un atacante podría encadenar pequeñas debilidades. Si necesita una evaluación de seguridad formal, vea la diferencia en nuestra comparación de auditorías técnicas, pruebas de penetración y revisiones de código.

La buena noticia es que la mayoría de los obstáculos para el lanzamiento en las apps creadas con IA se pueden corregir sin reescribir. El objetivo es encontrarlos mientras la única persona afectada es usted.