La estadística circula en dos mitades, y la gente suele citar la reconfortante. Los LLM producen código que compila correctamente cerca del 90% de las veces. La otra mitad: aproximadamente el 45% de ese código contiene vulnerabilidades de clase Top 10 de OWASP, la lista estándar de la industria sobre los fallos de seguridad graves más comunes, como errores de inyección y saltos de autenticación. Vale la pena ser precisos sobre lo que esto significa y lo que no, antes de que cause pánico o sea ignorado.
Lo que el número NO es
No es una afirmación de que el 45% de las apps creadas con IA sean hackeadas, ni de que el código generado sea excepcionalmente malo; los desarrolladores humanos también escriben código vulnerable, razón por la cual existe la lista de OWASP. Tampoco es un argumento para decir que las herramientas de codificación con IA son inútiles, ya que un desarrollador que revisa el resultado detecta gran parte de esto en el curso normal de su trabajo.
Lo que sí significa: lanza una moneda por cada generación y esas son aproximadamente las probabilidades de que el código contenga un fallo del catálogo de vulnerabilidades graves más conocido de la industria, mientras compila y hace la demo perfectamente. El fallo no tiene coste en el comportamiento visible. Ahí está la trampa.
Por qué el código que funciona no es código seguro
Los modelos de IA optimizan el éxito visual rápido, porque eso es lo que pedía el prompt y lo que el desarrollador puede verificar mirando. La seguridad es precisamente la propiedad que no puedes ver en la ventana de vista previa, y los modos de fallo documentados siguen esa tendencia. El control de acceso se implementa en el navegador en lugar de en el servidor, por lo que un usuario puede saltarse la comprobación modificando el código en su propia máquina; la app se ve idéntica en ambos casos. Los permisos de la base de datos se configuran de forma demasiado amplia para que todo funcione al primer intento, dejando los datos expuestos si cualquier otra parte de la app se ve comprometida. Los secretos se escriben directamente en los archivos porque gestionar variables de entorno es exactamente el tipo de tarea invisible que tanto los modelos como los principiantes omiten, y esas credenciales acaban en repositorios públicos de GitHub. Y los flujos auxiliares que tienen un peso real en la seguridad (recuperación de contraseñas, verificación OTP, gestión de sesiones) simplemente no se crean, porque nadie los muestra en la demo.
La posición de confianza del desarrollador lo empeora. Un operador no técnico no puede leer el código generado para verificar nada de esto, y las pruebas manuales ejercitan el camino ideal, no el salto de seguridad. La aplicación que “funciona perfectamente” y la aplicación que filtra los registros de todos sus clientes pueden ser la misma aplicación.
Qué revisar antes de que entren usuarios reales
Una auditoría mínima, en términos sencillos. Primero, aplicación en el lado del servidor: confirma que lo que un usuario puede ver se decide en el servidor o en las reglas de la base de datos, no ocultando botones en la interfaz. Segundo, postura de la base de datos: las reglas deben denegar por defecto y conceder permisos de forma restringida; en herramientas basadas en Supabase como Lovable, esto significa leer realmente las políticas RLS, no confiar en que el prompt las generó correctamente. Tercero, higiene de secretos: busca claves y cadenas de conexión hardcodeadas en el repo, especialmente si el proyecto se sincronizó alguna vez con un repositorio público. Cuarto, los flujos olvidados: que el restablecimiento de contraseñas, la expiración de sesiones y las restricciones de registro existan y funcionen. Quinto, la prueba del segundo usuario: crea dos cuentas e intenta acceder a los datos de un usuario desde la sesión del otro, incluso editando las URLs directamente. Nada de esto es exótico; todo es exactamente lo que la generación de código omite.
Y ten en cuenta la cláusula de mantenimiento: esto no es una revisión de una sola vez. Cada regeneración es una nueva tirada de los mismos dados, por lo que el bucle de corrección en una función de autenticación implica volver a verificar la capa que ya habías verificado, y pagar por la ronda que hace esa verificación. Esa carga de re-verificación es una de las caras del problema del Día Dos: la auditoría que haces hoy es la auditoría que tendrás que repetir tras el próximo cambio.
La bifurcación honesta
Esa lista de auditoría representa el coste real de ese porcentaje del 45 %, y hay exactamente dos formas de afrontarlo. Asumir la revisión: que tú o un desarrollador de confianza reviséis el código generado en cada iteración, tratando a la IA como a un junior muy rápido cuyo trabajo de seguridad debe revisarse siempre. Esta es una postura razonable para los desarrolladores, pero una fantasía para el resto. O bien, eliminar esa capa de la ecuación: para aplicaciones empresariales, como portales y herramientas internas, construye sobre una plataforma como Softr, donde la autenticación, los permisos y las reglas de acceso a los datos son infraestructura de la plataforma configurada visualmente en lugar de código generado por proyecto; así, la «lotería del 45 %» nunca afecta a la capa más crítica. Lo que no es una postura válida es la popular tercera opción: generar, echar un vistazo a la demo y lanzar. La estadística existe precisamente porque eso es lo que hace la mayoría de la gente.