La IA ya escribe una parte enorme del software que usamos. Según el 2026 GenAI Code Security Report de Veracode, en las organizaciones que la han adoptado la IA firma alrededor del 50% del código que se sube al repositorio, y ese código compila prácticamente siempre. Es uno de los saltos de productividad más grandes que ha vivido la ingeniería de software.
La otra mitad de la historia es la seguridad, y esta semana está en el centro de la conversación. Octubre es el Mes Europeo de la Ciberseguridad; el AI Congress Barcelona (20-22 oct) tiene como eje oficial de su edición la supervisión humana de la IA, junto a la seguridad y la soberanía tecnológica; y León acoge el 20ENISE de INCIBE (21-23 oct). Las tres citas apuntan a la misma conclusión que los datos: la IA programa cada vez mejor, y la seguridad del código llega cuando un ingeniero con criterio revisa lo que la IA propone.
¿Qué dice el informe de Veracode 2026 sobre el código generado por IA?
Veracode probó más de 100 modelos de lenguaje en tareas de programación con requisitos de seguridad. El resultado central: la tasa media de aprobación en seguridad es del 56%, prácticamente la misma que el 55% de 2025. Dicho de otro modo, en torno al 44-45% de las tareas generan código con una vulnerabilidad del OWASP Top 10.
| Indicador (Veracode 2026) | Resultado |
|---|---|
| Tasa media de aprobación en seguridad | 56% (55% en 2025) |
| Tareas con vulnerabilidad OWASP Top 10 | ~44% |
| Mejor modelo evaluado | 68% de aprobación |
| Inyección SQL | 83% de aprobación |
| Algoritmos criptográficos | 87% de aprobación |
| Cross-site scripting (XSS) | 15% de aprobación |
| Inyección en logs | 12% de aprobación |
| Python / Java | 63% / 30% de aprobación |
| Modelos especializados en código / generalistas / de razonamiento | 51% / 52% / 56% |
Chris Wysopal, cofundador de Veracode, lo resume así: los modelos pueden ser casi perfectos en sintaxis, pero siguen fallando en casi la mitad de las tareas donde hace falta seguridad. La Cloud Security Alliance llega de forma independiente a la misma cifra del 45% en su nota de investigación de 2026.
La buena noticia está en la propia tabla: la IA ya resuelve bien los fallos más conocidos, como la inyección SQL o la criptografía. Lo que queda pendiente es justo lo que depende del contexto, y eso es terreno del ingeniero.
¿Por qué un modelo más potente no cierra la brecha de seguridad?
Porque la seguridad depende de información que el modelo casi nunca tiene. Los datos apuntan en esa dirección:
- El tamaño y la especialización cambian poco. Los modelos especializados en código (51%) quedan a la altura de los generalistas (52%), y el mejor modelo evaluado se queda en el 68%.
- Más volumen exige más revisión. La Cloud Security Alliance observa que los desarrolladores asistidos por IA suben commits a un ritmo de 3 a 4 veces superior y generan hallazgos de seguridad a un ritmo 10 veces mayor.
- Más código, más verificación. CodeRabbit mide 1,7 veces más errores en el código generado por IA, y un estudio sobre unos 355 ingenieros registra un 14% más de pull requests, apenas un 1% más de producción efectiva y el triple de retrabajo.
El informe DORA de Google Cloud sobre el retorno de la IA en desarrollo (mayo 2026) ofrece la salida: las bases de ingeniería, y en particular el code review, son las que determinan si la IA genera retorno. La solución está en el proceso.
¿Qué ve un ingeniero que el modelo no ve?
El modelo ve un fragmento de código. El ingeniero ve el sistema, el negocio y el riesgo. En concreto:
- Qué dato es sensible. Un modelo trata igual un identificador interno que un número de cuenta. El ingeniero sabe qué datos son personales o regulados y cómo deben tratarse.
- Dónde está la frontera de confianza. Qué entradas vienen de usuarios, de terceros o de otros servicios, y por tanto deben validarse. Ahí nacen el XSS y la inyección en logs, los dos puntos más débiles del informe.
- La lógica de autorización. Quién puede hacer qué es una regla de negocio; un modelo puede generar un endpoint impecable que olvida comprobar permisos.
- Si la dependencia existe. La Cloud Security Alliance recoge que alrededor del 20% de las muestras de código generado por IA hace referencia a paquetes que no existen, una puerta abierta a paquetes maliciosos con ese nombre.
- El histórico del sistema. Incidentes pasados, decisiones de arquitectura y excepciones pactadas que no están en ningún prompt.
¿Quién es responsable de qué: la IA o el ingeniero?
| Tarea | IA (agentes y asistentes) | Ingeniero |
|---|---|---|
| Generar código y pruebas | Propone a gran velocidad | Decide qué entra |
| Detectar patrones conocidos (SQL, criptografía débil) | Primera pasada automática | Valida y prioriza |
| Validación de entradas y frontera de confianza | Aplica patrones si se le indican | Define qué es entrada no confiable |
| Autorización y reglas de negocio | Implementa lo especificado | Especifica y verifica |
| Dependencias | Sugiere librerías | Comprueba que existen, están mantenidas y son seguras |
| Datos sensibles y cumplimiento | Sigue reglas configuradas | Responde del tratamiento correcto |
| Aprobación para producción | Prepara el cambio | Firma el cambio |
Checklist práctico: cómo revisar de forma segura el código generado por IA
- Contexto primero. Antes de leer el código, entender qué hace el cambio, qué datos toca y quién lo usará.
- Entradas. Toda entrada externa se valida y se codifica a la salida (clave frente a XSS).
- Logs. Los datos de usuario se sanean antes de registrarse y nunca se registran secretos ni datos personales.
- Autorización. Cada endpoint o función comprueba permisos, también los generados "por completar".
- Dependencias. Cada paquete sugerido se verifica en el registro oficial: nombre exacto, mantenimiento y vulnerabilidades conocidas.
- Secretos. Claves, tokens y credenciales fuera del código, siempre en un gestor de secretos.
- Criptografía y configuración. Algoritmos actuales, valores por defecto seguros y cabeceras de seguridad activas.
- Análisis automático. Pasar análisis estático (SAST) y de dependencias antes de la revisión humana, para que el ingeniero dedique su tiempo al contexto.
- Pruebas de casos negativos. Además de comprobar que funciona, comprobar que falla bien ante entradas maliciosas.
- Trazabilidad. Dejar registrado qué generó la IA, quién lo revisó y qué se cambió.
¿Qué pide la regulación europea sobre supervisión humana?
El Reglamento Europeo de IA (Reglamento (UE) 2024/1689) se aplica con carácter general desde el 2 de agosto de 2026. Su artículo 14 exige que los sistemas de alto riesgo permitan a una persona entenderlos, detectar anomalías, ser consciente del sesgo de automatización, interpretar resultados, corregirlos o detenerlos. Para los sistemas del Anexo III (crédito, seguros, empleo, entre otros), esas obligaciones se exigen desde el 2 de diciembre de 2027.
Usar IA para programar mantiene el software en su nivel de riesgo original, ya que el nivel lo fija el uso final. Pero la lógica del artículo 14 es la misma que la de una buena revisión de código: una persona competente que entiende, corrige y puede parar. Los equipos que ya trabajan así llegarán a 2027 con la mitad del camino hecho. Lo explicamos en detalle en nuestro artículo sobre el Reglamento Europeo de IA y el humano en el bucle.
¿Cómo lo aplicamos en COHNECTI?
Con un principio sencillo: la IA acelera y el ingeniero responde.
- Dev Core, nuestro sistema de gobierno del desarrollo con IA, pone a los agentes a acelerar pruebas, revisión y entrega. El código que genera la IA pasa siempre por la revisión de un ingeniero antes de llegar a producción, y cada paso queda medido y trazable.
- Células de desarrollo con criterio senior, que conocen el negocio del cliente y deciden qué entra, qué se corrige y qué se para.
- Formación en IA para que los equipos de nuestros clientes sepan revisar código generado por IA con criterio de seguridad.
Para un banco, una aseguradora o una fintech, esto significa aprovechar toda la velocidad de la IA con un nivel de seguridad que depende de su propio estándar, no del modelo del momento.
Preguntas frecuentes
¿Es seguro el código generado por IA?
Puede serlo con revisión. Veracode mide una tasa media de aprobación en seguridad del 56% en más de 100 modelos, por lo que la revisión de un ingeniero sigue siendo el paso que garantiza la seguridad.
¿Qué vulnerabilidades introduce más la IA?
Según Veracode 2026, las que dependen del contexto: cross-site scripting (15% de aprobación) e inyección en logs (12%). En inyección SQL y criptografía los modelos rinden mucho mejor.
¿Los modelos nuevos son más seguros?
La mejora es pequeña: la tasa de aprobación pasó del 55% en 2025 al 56% en 2026, y los modelos especializados en código rinden como los generalistas.
¿Qué debe revisar un ingeniero en código generado por IA?
Validación de entradas, logs, autorización, dependencias, secretos, criptografía y configuración, además de las reglas de negocio y los datos sensibles.
¿El Reglamento Europeo de IA obliga a revisar el código?
Exige supervisión humana (Art. 14) en sistemas de alto riesgo; para los del Anexo III, desde el 2 de diciembre de 2027. La revisión de código es la práctica de ingeniería que mejor encaja con ese principio.
¿La revisión humana frena la productividad?
Bien organizada, la multiplica: el informe DORA de Google Cloud (mayo 2026) sitúa el code review entre los factores que determinan si la IA genera retorno.
Somos COHNECTI, tu partner tecnológico B2B.