Auditoría de una app hecha con IA: lo que el fundador necesitaba oír
ResultadoAuditoría de aplicación, mentoría para el fundador
El fundador construyó el producto él mismo con IA, y los clientes pagan por él. Hicimos una auditoría y una prueba de seguridad. Recibió un plan que puede llevar a cabo solo, no una lista de reproches.
fundador de productoCliente
Cómo empezó: el fundador quería saber si su producto hecho con IA aguantaría · Duración: de julio a octubre de 2026
Resumen
El fundador no es desarrollador profesional. Construyó el producto él mismo, con IA. El producto funcionaba y los clientes pagaban por él.
Quería saber tres cosas. ¿Aguantará? ¿Puede dejar entrar en el código a un segundo desarrollador? ¿Y podría hundirle un solo error?
El momento: la primera frase del veredicto
La auditoría completa era larga y correcta. Nadie la habría leído entera. Por eso la primera frase del veredicto decía: “Nada de esto es el Armagedón.”
La mayoría de las correcciones importantes eran de unas pocas horas cada una. El fundador necesitaba saber por dónde empezar, no oír que todo estaba mal.
Qué encontramos
El código no era malo. Era inconsistente. Es lo típico en el código escrito por IA.
La IA hace bien una comprobación de seguridad en un sitio y se la salta en el siguiente. Ajustes que deberían ser obligatorios se quedan como opcionales. La operación a menudo depende de una sola persona. La IA le escribirá el código. No le dirá qué se le olvidó configurar.
Cómo lo verificamos
Una prueba de seguridad no puede provocar el incidente que busca. Por eso verificamos los riesgos sin acceso a los datos. A menudo basta con la diferencia en la respuesta del servidor entre un punto protegido y uno sin proteger.
Sin datos reales, sin adivinar contraseñas, sin escrituras. El informe termina con una lista de lo que no hicimos.
Qué recibió el fundador
Dividimos la auditoría en tres partes:
- un veredicto breve de unas pocas páginas con cosas para una tarde,
- hallazgos con los puntos exactos del código,
- estándares a los que puede volver a medida que avance el desarrollo.
No redactamos las recomendaciones como “esto lo tienes mal”. Escribimos lo que le desbloquea cada corrección: un segundo desarrollador, el primer cuestionario de seguridad de un cliente, un fin de semana tranquilo.
Qué desaconsejamos
La auditoría ofrecía una venta fácil: una gran reescritura y una arquitectura nueva. Escribimos lo contrario. La estructura actual del código es suficiente. Las reglas más estrictas en el código llegan poco a poco, empezando por el inicio de sesión y los permisos. Ninguna gran reescritura de golpe.
El consejo más caro es técnicamente correcto y llega demasiado pronto.
Qué salió mal
Enviamos los primeros hallazgos como una lista justo después de la primera llamada. Una lista sola no bastaba. Lo que ven los clientes va primero. Lo que nadie ve hasta que se rompe puede esperar. Por eso el veredicto tiene un orden de pasos, no solo una lista.
Qué cambió
El fundador sabe qué hay bajo la superficie de su producto. Tiene un orden de pasos que puede llevar a cabo solo. El código y todo lo que dejamos por escrito le pertenecen.
Qué entregamos
- Auditoría técnica
- Prueba de seguridad sin tocar datos
- Veredicto y orden de pasos
- Estándares para el desarrollo futuro
