Un equipo de seis ingenieros adopta asistentes de codificación con IA. Tres meses después, el volumen de pull requests ha crecido un 40%. Las PRs son más largas, llegan más seguidas, y el tiempo disponible para revisar cada una no ha cambiado — sigue habiendo seis personas y las mismas horas al día. Algo tiene que ceder, y lo que cede es el escrutinio por línea de código.
Nada de esto es hipotético. Es la situación operativa de la mayoría de los equipos de desarrollo en 2026, y tiene una consecuencia directa para la seguridad que los datos de este año permiten cuantificar con precisión.
Lo que dicen los datos de 2026
Veracode lleva desde 2025 midiendo sistemáticamente la seguridad del código que generan los modelos de lenguaje. Su informe GenAI Code Security, sobre 80 tareas de codificación ejecutadas contra más de 100 modelos, encontró que el código generado introduce vulnerabilidades de seguridad conocidas en el 45% de los casos. No vulnerabilidades exóticas: inyección SQL (CWE-89), cross-site scripting (CWE-80), inyección en logs (CWE-117) y criptografía débil (CWE-327) — las categorías que cualquier escáner SAST detecta desde hace una década.
La actualización de marzo de 2026 añade dos hallazgos más incómodos. Primero: la tasa de aprobado en seguridad lleva estancada en torno al 55% durante todo el período medido, mientras los benchmarks de capacidad de codificación de esos mismos modelos no han dejado de mejorar. Los modelos escriben código cada vez más correcto funcionalmente — la corrección sintáctica supera el 95% — e igual de inseguro que antes. Segundo: los modelos más grandes no lo hacen mejor. Las afirmaciones públicas de los proveedores sobre entrenamiento consciente de seguridad no se corresponden con los resultados medidos en pruebas estandarizadas.
Hay un tercer dato, anterior pero más relevante que nunca, de un estudio de Stanford presentado en ACM CCS: los participantes con acceso a un asistente de IA no solo escribieron código significativamente menos seguro que el grupo de control — además creían con más frecuencia que su código era seguro. La relación entre confianza en el asistente y seguridad del resultado era inversa: quienes más confiaban en la IA producían las soluciones más vulnerables.
Combina las tres piezas: el código generado falla en seguridad casi la mitad de las veces, la tendencia no mejora con modelos mejores, y el humano que lo acepta tiende a revisarlo con menos escepticismo del que aplicaría a su propio código. Ese es el escenario real, no el de las demos.
El problema no es la IA — es la aritmética
Sería un error leer estos datos como un argumento contra los asistentes de codificación. El código escrito por humanos también contiene vulnerabilidades; ninguna de las categorías en las que fallan los modelos es nueva. La diferencia está en otra parte: en la relación entre volumen de código y capacidad de revisión.
Microsoft y Google declararon ya en 2025 que entre el 25% y el 30% de su código nuevo lo genera IA, con repositorios internos que superan el 50% — y las cifras suben cada trimestre. El código nuevo de una organización ya no se produce a la velocidad a la que teclean sus ingenieros; se produce a la velocidad a la que aceptan sugerencias.
La revisión humana, en cambio, no ha escalado. Revisar código sigue costando lo mismo por línea que en 2020 — de hecho cuesta más, porque revisar código que no has escrito tú exige reconstruir una intención que no existe: nadie "pensó" ese código. Cuando el volumen de entrada se multiplica y la capacidad de revisión permanece constante, el escrutinio por línea cae de forma matemáticamente inevitable. No es un fallo de disciplina del equipo. Es aritmética.
El resultado es que la vulnerabilidad de inyección SQL que antes tenía dos oportunidades de ser detectada — al escribirla y al revisarla — ahora tiene cero coma algo: el modelo la genera con fluidez, y el revisor humano, con el doble de PRs en cola y la confianza extra que documentó Stanford, la aprueba.
El escaneo automatizado deja de ser una buena práctica
Durante años, ejecutar SAST y detección de secretos en cada push fue una recomendación de madurez: los equipos serios lo hacían, los demás confiaban en la revisión de código. Esa segunda opción acaba de dejar de existir. Si la revisión humana ya no puede sostener el escrutinio por línea, el análisis automatizado en el pipeline pasa de ser la segunda red de seguridad a ser la única que escala al mismo ritmo que la generación de código.
Un escáner no se fatiga con la PR número cuarenta del día. Las reglas de Opengrep detectan la inyección SQL con la misma fiabilidad en la línea 10 que en la línea 10.000, la haya escrito un humano, un modelo o un humano aceptando lo que propuso un modelo. Y las cuatro categorías que Veracode identifica como los fallos sistemáticos de los modelos — inyección SQL, XSS, log injection, criptografía débil — son precisamente el terreno donde el análisis estático es más fuerte.
Un ejemplo del tipo de código que está atravesando revisiones ahora mismo:
# Sugerencia del asistente — compila, pasa los tests, cierra el ticket@app.get("/users/search")def search_users(q: str, db: Session = Depends(get_db)): """Busca usuarios por nombre con coincidencia parcial.""" query = f"SELECT id, name, email FROM users WHERE name LIKE '%{q}%'" return db.execute(text(query)).fetchall()Tipado correcto, docstring, convención de nombres impecable — e inyección SQL de libro en la interpolación de q. La versión con parámetros preparados le habría costado al modelo exactamente el mismo esfuerzo, pero el corpus de entrenamiento contiene millones de ejemplos con interpolación directa, y Veracode midió lo que eso produce: ante la disyuntiva entre el patrón seguro y el inseguro, los modelos eligieron el inseguro en el 45% de las ocasiones.
Hay algo peor que el error: su presentación. Los revisores humanos calibran el escepticismo con señales de superficie — código desordenado, nombres inconsistentes, ausencia de comentarios — y el código generado por IA no dispara ninguna. Es uniforme, está documentado, parece escrito por alguien cuidadoso. La fluidez funciona como camuflaje: la combinación exacta contra la que la heurística de un revisor con prisa no tiene defensa. Un escáner no usa señales de superficie — sigue el flujo de datos, y la interpolación de q en la query es igual de detectable venga de donde venga.
Hay un segundo frente menos comentado: los secretos. Los asistentes de IA reproducen los patrones que ven, y los ejemplos con credenciales hardcodeadas abundan en su entrenamiento y en el contexto que se les pasa. Un desarrollador que pega un fichero de configuración en el prompt para pedir ayuda puede recibir de vuelta código con esa misma credencial incrustada — y aceptarla con el resto de la sugerencia. La detección de secretos en cada push (Gitleaks, en el caso de Gerion) cubre exactamente el hueco que la revisión apresurada deja abierto.
Medir la deuda a la velocidad a la que se genera
Queda la pregunta de gestión: si el código — y con él la deuda de seguridad — se genera más rápido, ¿cómo sabes si tu capacidad de remediación sigue el ritmo?
Contar hallazgos no responde a eso. La métrica útil es la relación entre la velocidad a la que la deuda entra y la velocidad a la que sale. El Financial Impact Engine de Gerion expresa ambas en la misma unidad: la Security Debt agregada en euros y el Fix Rate del período. Si tu equipo adoptó asistentes de IA en el último trimestre, la comparación de esas dos curvas antes y después de la adopción es el dato que responde a la pregunta que tu CISO va a hacer tarde o temprano: ¿estamos generando deuda de seguridad más rápido de lo que la pagamos?
Para la mayoría de los equipos que hemos visto, la respuesta honesta es que no lo saben — porque miden la deuda en número de hallazgos críticos, una métrica que no distingue entre un CVE en una rama de feature y una inyección SQL generada por IA que acaba de llegar a main con multiplicador 10×.
La conclusión práctica
Los asistentes de codificación han cambiado la economía de escribir software y no van a desaparecer — ni deberían. Lo que sí exige revisión es la arquitectura de seguridad que se diseñó para un mundo donde el código se escribía a mano y se revisaba con calma. Tres ajustes concretos:
- SAST y detección de secretos en cada push, sin excepciones. No como aspiración de madurez — como el único control cuyo coste por línea no crece con el volumen.
- Tratar el código generado por IA con el mismo escrutinio que el de un contribuidor externo. El estudio de Stanford es claro: el sesgo va en la dirección contraria, y corregirlo requiere proceso, no voluntad.
- Medir la deuda de seguridad como flujo, no como foto. La pregunta relevante en 2026 no es cuántos hallazgos tienes — es si tu Fix Rate crece al mismo ritmo que tu velocidad de generación de código.
El 45% de Veracode no es un argumento para escanear el código generado por IA. Es un argumento para escanear todo el código, siempre — porque ya no puedes permitirte asumir que alguien lo leyó con atención antes de que llegara a tu rama de producción.