El 45% del código que tu "app hecha con IA" generó tiene una vulnerabilidad conocida, y probablemente nadie la revisó

"Vibe coding" es el término que se popularizó para describir algo que ya está pasando en miles de negocios pequeños ahora mismo: describirle a una IA lo que quieres que haga tu sitio o tu app, dejar que escriba todo el código, revisar que funcione visualmente, y publicarlo. Funciona sorprendentemente bien para poner algo en pie rápido — ese es exactamente el problema. "Funciona" y "es seguro" son dos cosas distintas, y la primera es mucho más fácil de verificar a simple vista que la segunda.

Los números ya están sobre la mesa. Veracode encontró que 45% del código generado por modelos de IA contiene al menos una vulnerabilidad del OWASP Top 10 — la lista de referencia de los fallos de seguridad más comunes y peligrosos en aplicaciones web. Escape.tech fue más allá y analizó aplicaciones reales construidas con herramientas de vibe coding: encontró más de 2.000 fallos críticos repartidos en 5.600 apps. Y el 22 de junio de este año, el NCSC del Reino Unido —el equivalente británico de un CERT nacional— publicó una advertencia formal sobre la práctica, con una frase que resume bien el momento actual: "no estamos ahí todavía. Calibra tu enfoque según la realidad de hoy, no el potencial de mañana."

El motivo técnico detrás de estas cifras no es que la IA sea mala programando — en muchos sentidos es sorprendentemente buena, y eso es justamente lo que genera la falsa sensación de seguridad. El problema, según el propio NCSC, tiene tres causas concretas: los modelos están optimizados para que el código funcione, no para que sea seguro; tienden a replicar patrones inseguros que aprendieron de código de entrenamiento que tampoco era seguro; y en muchos casos generan código lo suficientemente denso u opaco como para que sea difícil, incluso para alguien con criterio, notar dónde está el problema con solo mirarlo.

Esto no es un argumento para dejar de usar estas herramientas — sería como decirle a alguien que deje de usar un taladro eléctrico porque a veces alguien se lastima con uno. Es un argumento sobre qué tan responsable es publicar sin supervisión algo que puede terminar manejando datos de clientes, procesando pagos, o simplemente estando expuesto a cualquiera en internet. La recomendación del NCSC es clara y no exige convertirte en experto en ciberseguridad: la persona que acepta el código —tú, o quien administre tu sitio— tiene que entender lo que ese código hace antes de publicarlo, no solo confirmar que la pantalla se ve como esperabas. Si nadie en tu equipo puede leer el código y explicar en una frase qué hace cada parte sensible (dónde se guardan contraseñas, cómo se validan formularios, quién puede acceder a qué), ese código no debería estar sirviendo tráfico real todavía.

Para un negocio pequeño que no tiene un desarrollador en plantilla, la solución práctica no es contratar una auditoría de seguridad cara para cada sitio hecho con IA — es más simple y más barata que eso: correr el código generado por un escáner de vulnerabilidades automatizado antes de publicarlo (hay opciones gratuitas y de bajo costo para las fallas más comunes), revisar específicamente cómo se manejan contraseñas, formularios y cualquier dato de usuario, y tratar cualquier funcionalidad que toque pagos o información personal con más escepticismo que el resto. La velocidad que ganas usando IA para construir es real y vale la pena aprovecharla. Lo que no puedes seguir asumiendo gratis es que "funciona bien en la demo" significa "está listo para producción" — son preguntas distintas, y solo una de las dos la puede responder el propio modelo que escribió el código.