¿Es realmente seguro el código construido por IA? Las preguntas frecuentes de un constructor

Recibo alguna versión de esta pregunta en casi cada llamada de incorporación, normalmente formulada con cuidado, como si la persona que pregunta medio esperara que la convenzan de dejar de preocuparse. No deberían dejar de hacerlo. La seguridad es una de las pocas áreas donde una dosis saludable de paranoia está correctamente calibrada, sin importar si el código lo escribió un humano o un modelo. Estas son las preguntas que realmente me hacen, respondidas de la forma más directa posible.

¿El código escrito por IA es menos seguro que el escrito por un humano?

En promedio, y sin supervisión, sí — ligeramente. Un estudio de Stanford de hace algunos años (Perry et al., a menudo citado como el primer análisis serio de esto) encontró que los desarrolladores que usaban un asistente de codificación con IA producían código menos seguro que un grupo de control y —esta es la parte que debería preocuparte más— calificaban su propio código como más seguro de lo que realmente era. La confianza subió mientras la calidad bajaba. Los análisis de seguridad de código GenAI más recientes de Veracode también le ponen un número aproximado a esto: alrededor de 4 de cada 10 muestras de código generado por IA que probaron introdujeron al menos una falla explotable, generalmente algo mundano como una validación de entrada faltante o un valor predeterminado débil. Nada de esto significa que el código escrito por IA esté condenado inherentemente. Significa que el código de IA sin revisar conlleva el mismo riesgo que el código humano sin revisar, y ahí es donde realmente vive el peligro: en lo de "sin revisar". Un modelo que escribe rápido y nunca se verifica cometerá los mismos errores que un desarrollador junior un viernes por la tarde — solo que más rápido y en mayor cantidad.

¿Qué pasa con mis claves de API y secretos?

Este es el que realmente me quita el sueño, porque es el error que es invisible hasta que deja de serlo. El modo de fallo no es dramático — nadie sufre una brecha en su servidor al estilo de una película de hackers. Es una clave que se pega en un chat, se refleja en un archivo generado, se confirma (commit) y queda silenciosamente en texto plano en un repositorio seis meses después, cuando alguien ejecuta un escáner de secretos por curiosidad. En esta plataforma, los secretos nunca viven en el código fuente generado — se inyectan en tiempo de ejecución desde un almacén cifrado, delimitado a tu cuenta (tenant), y a los agentes de compilación se les indica que los referencien por nombre, nunca por valor. Pero si estás construyendo en otro lugar, o pegando credenciales directamente en una ventana de chat con cualquier herramienta, asume que ese texto ahora forma parte de algún registro relacionado con entrenamiento, a menos que el proveedor indique explícitamente lo contrario. Rota por principio cualquier cosa que hayas escrito alguna vez en un cuadro de chat, el mismo día que termines de probar.

¿Alguien puede hackear mi sitio mediante un prompt, como un ataque de inyección de prompts?

Aquí se mezclan dos cosas distintas, y la diferencia importa. La inyección de prompts contra el creador —alguien que engaña a la IA que está construyendo tu app para que haga algo que no pediste— es un riesgo real y estudiado, y por eso los agentes de compilación operan con permisos de herramientas delimitados en lugar de acceso total a la shell, y por eso cualquier cosa que toque tu sistema de archivos o tu proceso de despliegue pasa por un registro de acciones explícito que puedes auditar después. La inyección de prompts contra tu app publicada es un asunto aparte que solo aplica si tu propia app incorpora un LLM en tiempo de ejecución —un chatbot de soporte, una función de búsqueda con IA, ese tipo de cosas—. Si es así, trata cualquier texto que un usuario pueda escribir como entrada no confiable para ese modelo, igual que lo tratarías como entrada no confiable para una consulta SQL. La regla es antigua, lo nuevo es solo qué sistema está interpretando la cadena de texto.

¿El creador revisa su propio código en busca de vulnerabilidades antes de publicarlo?

Las verificaciones automatizadas detectan de forma confiable lo aburrido y frecuente: secretos codificados en el código, falta de autenticación en un endpoint que claramente la necesita, SQL construido por concatenación de cadenas en lugar de parámetros, dependencias con un CVE conocido. Lo que no detectan bien son las fallas de lógica de negocio — el tipo en el que cada línea de código individual está bien y la vulnerabilidad está en el hueco entre dos funciones que nadie pensó en revisar juntas. Un código de descuento que se acumula infinitamente con un bono de referido. Un flujo de restablecimiento de contraseña que filtra si un correo existe en el sistema. Eso requiere a alguien que entienda para qué sirve la app, no solo qué hace el código, y ningún escáner —de IA o de otro tipo— las encuentra de forma confiable todavía. La revisión automatizada es un piso, no un techo.

¿Qué pasa con los paquetes de terceros que instala? ¿Eso es un riesgo de cadena de suministro?

Sí, y honestamente es un riesgo real más grande que el propio código escrito por la IA. La mayoría de las apps son entre el 80 y el 95% dependencias en número de líneas; el código que escribe un creador es una capa delgada sobre npm, PyPI o el ecosistema que use el stack. Un paquete malicioso o secuestrado puede comprometerte sin importar quién o qué escribió el código pegamento a su alrededor — mira los incidentes de event-stream y colors.js para ver cómo se desarrolla esto en la práctica. Las mitigaciones son sencillas y efectivas: fija versiones en lugar de seguir la última, prefiere paquetes con un historial de mantenimiento real frente a los publicados la semana pasada, y ejecuta una auditoría de dependencias (`npm audit`, `pip-audit`, o lo que corresponda a tu stack) como hábito permanente, no como un paso único antes del lanzamiento.

¿Quién es responsable si hay una brecha de seguridad?

Tú lo eres — legalmente, casi siempre, si es tu app y los datos son de tus clientes. Esto sorprende a quienes asumen que "lo escribió la IA" traslada la responsabilidad a otro lado. No lo hace, de la misma forma que contratar a un contratista no traslada la responsabilidad de una infracción del código de construcción fuera del propietario del inmueble. Las plataformas asumen responsabilidad por la infraestructura que controlan: cómo se almacenan los secretos, cómo se aísla la información de cada cuenta, si la capa de alojamiento en sí está parcheada. Pero la lógica de la aplicación que especificaste, los datos que decidiste recopilar y los términos que ofreciste a tus usuarios son tuyos. Si manejas algo sensible —datos de pago, información de salud, cualquier cosa bajo el RGPD o la CCPA— lee el acuerdo real de procesamiento de datos de la plataforma que uses en lugar de asumir que "creado con IA" implica alguna capa adicional de cobertura legal. No la implica.

Una fundadora me dijo una vez, medio en broma, que confiaba más en el código de la IA que en el suyo propio porque "al menos no se cansa a las 2 de la mañana". Puede ser. Pero los humanos cansados suelen saber que están cansados. Una IA no tiene idea de que acaba de cometer un error, y te dirá que el código está listo con exactamente el mismo tono seguro, ya sea que esté impecable o plagado de fallas. La confianza no es una señal de seguridad, venga de donde venga.

¿Debería pagar por una auditoría de seguridad real antes de lanzar?

Si vas a procesar pagos, almacenar cualquier cosa que un regulador consideraría información personal identificable, o construir para un cliente empresarial que de todos modos pedirá un informe SOC 2 — sí, y no dejes que el costo te disuada. Una auditoría enfocada en una app pequeña cuesta desde unos cientos hasta unos pocos miles de dólares dependiendo del alcance, lo cual es barato en comparación con una carta de notificación de brecha. Si estás construyendo un proyecto de hobby, una herramienta interna o algo sin datos de usuario reales en juego, una auditoría paga es excesiva; usa en su lugar la capa gratuita y económica — análisis de dependencias, una revisión manual de cada límite de autenticación (¿puede el usuario A ver las cosas del usuario B cambiando una URL?) y un segundo par de ojos humanos sobre cualquier cosa que involucre dinero o contraseñas.

¿Cuál es el error de seguridad más común y cuándo suele ocurrir?

No en el lanzamiento — tres meses después, cuando la app funciona y ya nadie la está mirando. Es una ruta de administrador sin protección porque solo la probó quien la construyó, con su propia sesión iniciada. Es un endpoint de depuración que devuelve trazas de pila completas en producción. Es una contraseña predeterminada en una base de datos que se suponía que era "solo para pruebas" y nunca se rotó. Nada de esto es exótico. Es el equivalente en seguridad a dejar una llave de repuesto bajo el felpudo porque tenías prisa esa vez y luego olvidaste que estaba ahí. La solución no es una mejor herramienta, es un hábito de cinco minutos: una vez al mes, mira tu app como lo haría un atacante durante cinco minutos antes de mirarla como lo haría un creador orgulloso.