La Trampa del Piloto Automático: Por Qué el Código Generado por IA Falla la Revisión de Seguridad

La IA lo escribió. La demo funcionó. Se desplegó.

Luego alguien leyó el código de verdad.

Esta es la historia de casi todos los productos que nos llaman a auditar. Un fundador entrega rápido con la IA en piloto automático, la cosa funciona en el camino feliz, los inversores quedan impresionados — y entonces una revisión de seguridad (o un atacante) encuentra las partes que nadie miró.

La IA es lo mejor que le ha pasado a la velocidad de desarrollo en una década. También es lo mejor que les ha pasado a los atacantes en una década. Ambas cosas son ciertas.

La Trampa del Piloto Automático

Aquí está la trampa, y es seductora: el código generado por IA parece terminado.

Compila. Tiene comentarios. Los nombres de variables son buenos. Maneja el caso que preguntaste. Se siente como si lo hubiera escrito un ingeniero senior, así que lo revisas como si lo hubiera escrito un ingeniero senior — es decir, lo ojeas y sigues.

Pero la IA no tenía un modelo de amenazas. No estaba pensando en el atacante. Optimizó para "haz que la feature funcione", porque eso es lo que pediste. La seguridad es todo lo que pasa cuando alguien usa tu código de una forma que no pediste — y esa es exactamente la parte que el piloto automático se salta.

El resultado es código que está 95% bien y catastróficamente mal en el 5% que importa.

Los Patrones Que Vemos Cada Vez

Después de auditar decenas de bases de código construidas con IA, las fallas riman. Estas son las que encontramos en casi cada proyecto.

1. Secretos commiteados al repo

API keys, URLs de base de datos, secretos de firma JWT — hardcodeados en el código o incrustados en el bundle del cliente. La IA felizmente inserta una key para que un ejemplo funcione, y nunca se vuelve a sacar. Encontramos credenciales de producción vivas en el historial de git constantemente.

2. Autenticación sin autorización

La IA construye una pantalla de login. No construye control de acceso. Así que cualquier usuario autenticado puede leer los datos de cualquier otro usuario cambiando un ID en la URL. Esto es IDOR (Referencia Directa a Objeto Insegura), y es el bug serio más común que encontramos. "¿Este usuario inició sesión?" no es la misma pregunta que "¿este usuario tiene permiso para tocar este registro?".

3. Injection — incluyendo el tipo nuevo

El SQL y command injection clásicos siguen apareciendo cuando la IA concatena strings en queries. Pero el nuevo es prompt injection: features de IA que pasan input no confiable del usuario directo a un LLM que puede llamar herramientas, consultar bases de datos o enviar email. Si tu agente puede tomar acciones, el input de tu usuario ahora es ejecutable.

4. Defaults inseguros dejados abiertos de par en par

CORS: *. Modo debug encendido en producción. Mensajes de error verbosos filtrando stack traces y rutas internas. Roles IAM en la nube con Allow * porque eso hizo que el deploy dejara de fallar. El piloto automático elige el default que hace desaparecer el error — que casi siempre es el menos seguro.

5. Podredumbre de dependencias

Versiones sin fijar, paquetes abandonados, dependencias transitivas con vulnerabilidades conocidas. La IA agarró lo que tenía en su entrenamiento, que puede tener años de antigüedad, y nadie corrió una auditoría.

6. Sin rate limiting, sin validación de input

Los endpoints funcionan. También aceptan un payload de 50MB, pueden ser llamados diez mil veces por segundo, y confían en cada campo que el cliente envía. Bien en una demo. Una puerta abierta de par en par en producción.

Por Qué el Alto Rendimiento Lo Empeora

La mayoría de los consejos de seguridad asumen que puedes simplemente agregar un check. Pero los productos que auditamos a menudo están construidos para escala — sistemas en tiempo real, de alto throughput, de baja latencia, donde un check ingenuo en el hot path es inviable.

Aquí es donde el piloto automático realmente se desmorona. La IA escribirá alegremente código que es o rápido o seguro, rara vez ambos. Bajo concurrencia, produce condiciones de carrera: dos requests leen el mismo balance, ambos pasan el check, ambos escriben. Doble gasto. Bajo carga, el rate limit faltante no es solo un agujero de seguridad — es una factura y una caída.

Asegurar un sistema de alto rendimiento no se trata de atornillar checks. Se trata de diseñar las invariantes para que el camino rápido sea también el camino seguro. Eso requiere a alguien que ya lo haya hecho antes. El piloto automático no lo ha hecho.

Por Qué la IA Produce Esto (y Seguirá Haciéndolo)

Esto no es un modelo que necesita una versión más. Es estructural:

• Optimiza para "funciona", no para "no se puede abusar". Pediste una feature, no un modelo de amenazas.
• Está entrenada con código promedio. La mayoría del código en internet es inseguro. El promedio es el problema.
• Se equivoca con confianza. La IA escribirá un check de autenticación que parece correcto y es trivialmente evadible, sin matices, porque no tiene concepto de la duda.
• No tiene visión de sistema. La seguridad vive en las costuras entre componentes. La IA ve un archivo a la vez.

Modelos mejores hacen que el código parezca más terminado. Eso amplía la trampa, no la cierra.

Cómo Lo Arreglamos

Cuando auditamos un sistema construido con IA, no te entregamos un PDF de 60 páginas y nos vamos. Hacemos el trabajo:

1. Modelo de amenazas primero. ¿Qué datos vale la pena robar? ¿Qué puede alcanzar un usuario autenticado? ¿Qué puede uno anónimo? Mapeamos la superficie de ataque antes de leer una línea.
2. Leemos las costuras. Autenticación, autorización, fronteras de input, fronteras de confianza, la superficie de herramientas del agente de IA. El código peligroso está entre los archivos, no en ellos.
3. Probamos los bugs. No reportamos "posible IDOR". Te mostramos el request que lee los datos de otro usuario, y luego el arreglo.
4. Endurecemos el hot path. Para sistemas de alto rendimiento, hacemos que el camino seguro sea el camino rápido — operaciones atómicas, locking correcto, rate limits que no destruyen la latencia.
5. Re-testeamos. Verificamos que cada arreglo aguante, y te dejamos los tests para que no haya regresiones.

Tú sigues moviéndote rápido. Nosotros nos aseguramos de que rápido no signifique vulnerado.

Cuándo Deberías Preocuparte

Sé honesto sobre dónde estás:

• ¿Pre-lanzamiento, sin usuarios reales, sin datos reales? Despliega, aprende, vuelve antes de escalar.
• ¿Cobrando pagos, manejando datos personales, o a punto de entrar a due diligence? Esto no es opcional. La auditoría es más barata que la brecha, y mucho más barata que la brecha durante una ronda.
• ¿Agentes de IA que pueden tomar acciones en nombre de los usuarios? Tienes una superficie de ataque que la mayoría de los equipos de seguridad nunca ha visto. Pon ojos en ella ahora.

Hagámoslo Seguro y Rápido

Si entregaste rápido con IA y no estás seguro de qué hay debajo — ese es el estado normal de las cosas en 2026, y es exactamente para lo que estamos aquí.

Auditamos sistemas de alto rendimiento y construidos con IA, encontramos lo que el piloto automático dejó atrás, y lo arreglamos antes de que se convierta en un incidente.

Reserva 20 minutos con nosotros. Cuéntanos qué construiste y cómo. Te diremos qué miraríamos primero.

Sin alarmismo. Solo una lectura directa de dónde estás parado.

---

La próxima semana: Hicimos red team a un lote de MVPs construidos con IA. Esto es exactamente lo que se rompió.