En los proyectos que llevamos, la herramienta de IA para programar se elige por dos motivos: lo rápido que llega a un cambio que funciona, o lo que cuesta la licencia por persona. Nadie me ha preguntado nunca cuál escribe el código más seguro. Esa pregunta ya tiene respuesta, y es lo bastante incómoda como para cambiar unas cuantas decisiones.
Un índice construido sobre una metodología de la universidad australiana RMIT ha puntuado 16 modelos por la seguridad del código que producen. Dirijo Aivy, una agencia de automatización que nació en Melbourne y hoy trabaja también con pymes españolas, y he pasado la semana cruzando ese ranking con lo que veo en repositorios de clientes.
El titular no es que un modelo sea inseguro. Es que fallan los 16, que cada uno falla siempre por el mismo sitio, y que las herramientas que la mayoría usa por defecto, incluidos los agentes de IA que ya escriben código solos, están en la mitad baja de la tabla.
Qué mide el AI Trust Index de seguridad del código
Los benchmarks de programación de siempre preguntan si el modelo consigue que pasen los tests. Este pregunta otra cosa: cuando el código funciona, ¿es seguro? El índice pidió a cada uno de los 16 modelos generar aplicaciones idénticas en 11 frameworks, repitiendo cada combinación diez veces, y después pasó tres analizadores estáticos independientes por el resultado, verificando los hallazgos para quitar falsos positivos.
De ahí salen 1.760 codebases completas. La metodología nació como estudio con RMIT sobre seis modelos y Secure Code Warrior la amplió a 16. Lo de repetir diez veces importa más que la cifra del titular: es la forma de distinguir un modelo que ha tenido un mal día de un modelo que tiene un mal hábito.
Conviene decir qué no mide. Una nota alta significa que el modelo tiende a producir menos vulnerabilidades verificadas, no que razone mejor sobre un repositorio grande ni que llegue antes a un diff. Ese otro eje lo comparamos en la guía de Cursor frente a GitHub Copilot. La seguridad es una dimensión de la elección, no toda la elección.
Ranking completo: de Claude Sonnet 5 a GPT 5 Mini
Claude Sonnet 5 encabeza la tabla con 80,4 sobre 100. Lo interesante es lo que hay debajo: entre el primero y el último hay casi 59 puntos, mucho más de lo que separa a esos mismos modelos en un benchmark de programación normal. En capacidad estas herramientas convergen. En seguridad, no.
Notas de seguridad del código, todos los modelos evaluados
Dos índices independientes. Usan tareas y escalas distintas, así que van en bloques separados y sus cifras no se pueden comparar entre sí.
SCW AI Trust Index
Nota sobre 100, más alto es mejor. Los 8 primeros de los 16 evaluados. Fuente: SCW AI Trust Index.
Índice de Endor Labs, este sí incluye GPT 5.6
Porcentaje de 200 tareas donde el código salió correcto y además seguro. Vara mucho más dura: el líder no llega a 3 de cada 10. Fuente: Endor Labs, 17 de julio de 2026.
De ahí para abajo los números caen rápido, y el patrón no es aleatorio. Hay cuatro modelos de Claude entre los nueve primeros, pero otros dos entre los cuatro últimos. O sea, que la marca es mal indicador de seguridad. Si lo que buscas es la vista de capacidad de la familia Claude y no la de seguridad, la tienes en qué modelo de Claude usar.
| # | Modelo | Puntuación |
|---|---|---|
| 1 | Claude Sonnet 5 | 80,4 |
| 2 | Claude Fable 5 | 76,4 |
| 3 | GPT 5.3 Codex | 75,3 |
| 4 | Claude Opus 4.8 | 74,5 |
| 5 | GPT 5.1 | 71,6 |
| 6 | Gemini 3.1 Pro | 66,6 |
| 7 | GPT 5.5 | 66,5 |
| 8 | Gemini 2.5 Pro | 65,6 |
| 9 | Claude Sonnet 4.5 | 65,2 |
| 10 | Gemini 3.5 Flash | 59,1 |
| 11 | Devstral 2 | 53,1 |
| 12 | Claude Haiku 4.5 | 50,7 |
| 13 | Claude Sonnet 4.6 | 45,5 |
| 14 | Gemini 2.5 Flash | 39,4 |
| 15 | Qwen3 Coder | 32,7 |
| 16 | GPT 5 Mini | 21,6 |
Ranking completo de los 16 modelos. Fuente: SCW AI Trust Index, julio de 2026.
Dónde quedan Codex y GPT 5.6 en seguridad del código
Al mirar esa tabla saltan dos preguntas. Codex sí está: GPT 5.3 Codex quedó tercero con 75,3, la mejor nota de cualquier modelo fuera de la familia Claude. GPT 5.6 no está, ni tampoco sus variantes Sol, Terra y Luna, así que no existe una nota de seguridad para el modelo que muchos equipos tienen abierto ahora mismo.
Ese hueco hay que decirlo, no taparlo. Si trabajas con GPT 5.6, lo más cerca que tienes es el abanico de los modelos de OpenAI que sí se probaron, y ese abanico es amplio.
Todos los modelos de OpenAI, en los dos índices
Escalas distintas, por eso van separadas. GPT 5.6 no tiene nota en el Trust Index: su único resultado medido viene de Endor Labs.
SCW AI Trust Index
Nota sobre 100. Fuente: SCW AI Trust Index.
Índice de Endor Labs
Porcentaje de tareas correctas y seguras. Fuente: Endor Labs, 17 de julio de 2026.
Entre GPT 5.3 Codex y GPT 5.5 hay casi nueve puntos, y GPT 5.1 se cuela en medio siendo más antiguo. El número de versión no predice la nota de seguridad dentro de OpenAI igual que tampoco lo hace dentro de Claude. Las tres variantes de GPT 5.6 se diferencian en profundidad de razonamiento y velocidad, no en postura de seguridad, y esas diferencias las desglosamos en la guía de GPT 5.6 Sol, Terra y Luna.
Hay un segundo índice que sí lo cubre. El AI Coding Agent Security Benchmark de Endor Labs lanza 200 tareas sacadas de 108 proyectos Python de código abierto sobre 77 clases de CWE, y solo da una tarea por buena cuando el código pasa las pruebas funcionales y las de seguridad. Con esa vara, GPT 5.6 Sol corriendo en Codex sacó un 23,5% el 17 de julio de 2026.
De ese bloque de abajo salen dos cosas que conviene subrayar. GPT 5.6 Sol mejora a GPT-5.5 dentro de Codex, pero solo 1,1 puntos, y GPT-5.5 pilotado desde Cursor les gana a los dos. El arnés que envuelve al modelo mueve el resultado casi tanto como el modelo, que es la misma lección que da la tabla de frameworks por otro camino.
La lectura práctica es corta. Codex tiene nota en los dos índices y aguanta. GPT 5.6 tiene un solo dato medido, de un único arnés y una única variante, así que trata a Sol como poco medido y a Terra y Luna como no medidos hasta que alguien los puntúe.
Ningún asistente de IA entrega código seguro
Estar arriba de la tabla sigue significando entregar agujeros. En las 1.760 codebases salieron una media de 15 vulnerabilidades confirmadas por proyecto, 4,3 de ellas graves. Y esa media incluye a los líderes. Sacar un 80,4 no quiere decir que Claude Sonnet 5 escriba código seguro. Quiere decir que escribe código menos inseguro que las alternativas.
La palabra que repiten los investigadores es predecible: todos los modelos dejan un patrón repetible de fallos de seguridad, según su consejero delegado, Pieter Danhieux. En mi experiencia esa es la frase más útil del estudio, porque a un fallo que sale siempre por el mismo sitio le puedes poner un control delante. A uno aleatorio, no.
Eso replantea la pregunta de compra. En vez de preguntar qué asistente es seguro, pregunta cuánto presupuesto de revisión te cuesta cada uno y si tu equipo lo tiene. Es una pregunta de proceso, no de herramienta, y es la que casi ningún equipo con el que hablamos en Aivy ha resuelto todavía.
CWE-532: el fallo del código generado con IA que más se repite
Hay una debilidad que domina sobre todas las demás. El CWE-532, información sensible escrita en ficheros de log, se confirmó 8.543 veces, casi el triple que el siguiente. El cross site scripting quedó segundo con 2.949 y las credenciales escritas a fuego, terceras con 1.348.
Vulnerabilidades más frecuentes en código generado con IA
Positivos verdaderos verificados en 1.760 codebases. Fuente: SCW AI Trust Index.
Lo incómodo del CWE-532 es que no se ve en una revisión normal. La aplicación funciona, los tests pasan y no hay nada raro hasta que alguien abre un fichero de log y encuentra un token, un correo o una ficha de cliente entera en texto plano. Es un fallo que descubres en un incidente, no en una pull request. Cómo encaja eso con la norma lo desarrollamos en la guía de cumplimiento de RGPD y Reglamento de IA.
Pagar más no compra código más seguro
El dato que debería replantear unas cuantas decisiones de compra es que aquí el precio no predice nada. El modelo más caro del estudio, Claude Fable 5 a 174,94 dólares por ejecución, quedó segundo. El más barato, Gemini 2.5 Flash a 0,58 dólares, puntuó por debajo de la media. Entre esos dos hechos hay una diferencia de precio de 300 veces.
Coste por ejecución frente a puntuación de seguridad
Las barras naranjas escalan al más caro, las verdes son la nota sobre 100. Fuente: SCW AI Trust Index.
Lo que sí se sostiene es la gama, no la marca ni el precio. Las gamas económicas se agolpan al fondo: Claude Haiku 4.5 con 50,7, Gemini 2.5 Flash con 39,4 y GPT 5 Mini con 21,6. Si tu equipo manda el trabajo en bloque a una gama mini o flash para ahorrar, ese ahorro lleva un coste de seguridad que no venía en la factura. La otra cara del cambalache la vemos en Cursor frente a Windsurf y Devin Desktop.
Ningún modelo escribe el código más seguro en todos los frameworks
El ranking general esconde algo importante: el líder cambia según lo que estés escribiendo. Claude Sonnet 5 encabeza la tabla agregada y no gana ni uno solo de los cinco frameworks que los investigadores desglosaron.
| Framework | Modelo más seguro |
|---|---|
| Java Enterprise API | GPT-5.1 |
| Java Spring | Claude Sonnet 4.5 |
| Python Django | Claude Opus 4.8 |
| C# (.NET) | GPT-5.5 |
| C | Claude Fable 5 |
Líderes por framework. Fuente: SCW AI Trust Index.
Claude Sonnet 4.5 va noveno en la general y gana en Java Spring. GPT-5.5 va séptimo y gana en C# punto NET. Si tu stack es uno de esos, la tabla general te está engañando y el número que te sirve es el de tu fila. Es la misma razón por la que una herramienta única para toda la casa aguanta mal el contacto con un código heterogéneo, algo que vemos a menudo trabajando como agencia de IA en Madrid con equipos que arrastran varios lenguajes.
Claude Sonnet 4.6: más nuevo no es más seguro
La línea más contraintuitiva del estudio está dentro de una misma familia. Claude Sonnet 4.5 saca 65,2. Claude Sonnet 4.6, que salió después, saca 45,5. Y luego Claude Sonnet 5 sube a 80,4. La seguridad no mejoró con el número de versión: bajó y después volvió a subir.
Puntuación de seguridad de Claude Sonnet por versión
Más alto es mejor, eje de 0 a 100. Fuente: SCW AI Trust Index.
La lección práctica es que actualizar de modelo no es automáticamente actualizar de seguridad, y nadie te va a avisar cuando vaya en la otra dirección. Las notas de versión hablan de capacidad. Si la seguridad te importa, el salto de versión hay que volver a probarlo en vez de darlo por bueno, la misma disciplina que aplicamos cuando aterriza un modelo de gama alta en Claude Opus 5 frente a GPT 5.6.
Seguridad del código con IA, RGPD y empresas españolas
El fallo más común del estudio es información personal escrita en ficheros de log, y aquí eso no es un detalle técnico neutro. Bajo el RGPD, los datos personales que acaban en tus logs son datos personales que tratas, con lo que eso arrastra: obligación de seguridad y, si esos ficheros se filtran, notificación a la AEPD en 72 horas.
Lo que lo empeora es dónde viajan los logs. Se mandan a plataformas de observabilidad, se adjuntan a tickets de soporte y se copian a buckets, muchas veces fuera de la UE. Así que un CWE-532 en una llamada de log generada por IA se convierte, sin que nadie lo decida, en una cuestión de residencia de datos además de una de seguridad. El estudio en sí lo contamos con más detalle en nuestra cobertura del ranking.
Peso de los tres fallos más frecuentes
Porcentaje sobre los 12.840 hallazgos de las tres clases principales, eje de 0 a 100. Calculado a partir de los recuentos del SCW AI Trust Index.
Y hay un detalle de calendario que conviene tener en el radar: el Reglamento Europeo de IA va desplegando obligaciones por fases, así que el listón de lo que hay que documentar sobre las herramientas que usas se mueve.
Lo que veo en los proyectos es que los equipos españoles han adoptado estos asistentes mucho más rápido que cualquier proceso para revisar lo que producen, y ese hueco pesa más que la elección de herramienta. Si trabajas con datos de terceros, como pasa en una asesoría o gestoría, la conversación deja de ser técnica bastante rápido.
Cómo elegir el asistente de IA que escribe código más seguro
El ranking sirve más como regla de reparto que como lista de la compra. Gama alta para todo lo que toque datos de clientes, credenciales o pagos. Gama económica para andamiaje, tests, prototipos desechables y herramientas internas donde el radio de daño es pequeño. Ese único corte se lleva la mayor parte del valor de la tabla.
Después, tres cosas te dan más que cambiar de modelo. Pasar un analizador estático específicamente por el código generado, no solo por el escrito a mano. Meter el CWE-532 en la lista de revisión, porque es el que no se va a anunciar solo. Y volver a probar cuando cambies de versión, en vez de fiarte del número.
Elige por stack usando la tabla de frameworks, no por marca. Manda el trabajo sensible a un modelo de gama alta. Mete un paso de análisis estático en el pipeline que corra contra el código generado, y trata las llamadas de log como la salida de más riesgo que produce el modelo.
Si quieres una segunda opinión sobre cómo está usando tu equipo estas herramientas, es justo el tipo de cosa que miramos en consultoría de IA, o puedes reservar una reunión y lo hablamos.
Preguntas frecuentes sobre seguridad del código con IA
¿Qué asistente de IA escribe el código más seguro?
Claude Sonnet 5 encabeza el SCW AI Trust Index con 80,4 sobre 100, por delante de Claude Fable 5 con 76,4 y GPT 5.3 Codex con 75,3. Ningún modelo salió limpio: el líder sigue produciendo vulnerabilidades verificadas.
¿Cuántas vulnerabilidades suele traer el código generado con IA?
El estudio encontró una media de 15 vulnerabilidades confirmadas por codebase, 4,3 de ellas graves, sobre 1.760 codebases de 16 modelos. Esa media incluye a los mejores modelos, así que es un suelo y no un peor caso.
¿Se puede poner en producción código generado por IA sin revisar?
No conviene. Todos los modelos evaluados produjeron vulnerabilidades verificadas, así que el código generado suele necesitar el mismo análisis estático y la misma revisión humana que cualquier otra aportación. El ranking te dice cuánta revisión presupuestar, no si puedes saltártela.
¿Un modelo más caro escribe código más seguro?
No. El modelo más caro del estudio, Claude Fable 5 a 174,94 dólares por ejecución, quedó segundo, mientras que el más barato, a 0,58 dólares, puntuó por debajo de la media. Precio y seguridad no mostraron relación fiable.
¿Qué es el CWE-532 y por qué importa tanto?
El CWE-532 es la escritura de información sensible en ficheros de log. Se confirmó 8.543 veces en el estudio, casi el triple que el siguiente fallo, y cuesta mucho detectarlo en revisión porque la aplicación se comporta con normalidad.
¿El RGPD se aplica a los datos que quedan en los logs?
Los datos personales en logs se tratan por lo general como datos personales que la empresa trata, con las obligaciones de seguridad que eso implica y la posible notificación a la AEPD en 72 horas. Conviene contrastar tu caso concreto con un asesor cualificado.
¿El mejor modelo es el mismo para todos los lenguajes?
No. Los resultados por framework dan líderes distintos: GPT-5.1 en Java Enterprise API, Claude Sonnet 4.5 en Java Spring, Claude Opus 4.8 en Python Django, GPT-5.5 en C# punto NET y Claude Fable 5 en C. Elige por stack.
¿Las gamas mini y flash valen para trabajo real?
Suelen quedar al fondo del ranking, con GPT 5 Mini en 21,6 y Gemini 2.5 Flash en 39,4. Encajan bien en andamiaje, tests y prototipos, pero son mala opción por defecto para código que toca datos de clientes o credenciales.
¿Actualizar a un modelo más nuevo mejora la seguridad?
No siempre. Claude Sonnet 4.6 sacó 45,5, por debajo de Claude Sonnet 4.5 con 65,2, antes de que Sonnet 5 subiera a 80,4. La seguridad no siguió al número de versión, así que conviene volver a probar tras actualizar.
¿Hace falta un desarrollador para actuar sobre esto?
Para el primer paso no. Decidir qué gama de asistente lleva el trabajo sensible es una decisión de política interna. Añadir análisis estático contra el código generado y montar la lista de revisión sí suele necesitar perfil técnico para hacerlo bien.
Seguridad del código con IA: lo que decide el riesgo en 2026
Lo que hay que llevarse no es el nombre que encabeza la tabla. Es que la diferencia entre modelos es de casi 59 puntos en seguridad mientras la diferencia en capacidad se estrecha, y que los fallos de cada modelo son lo bastante repetibles como para planificar alrededor. Eso convierte la elección de herramienta en un control de seguridad, una conversación muy distinta de la de productividad que casi todos hemos tenido hasta ahora, y que se agudiza según los agentes escriben más código sin nadie mirando cada paso.
Si estás valorando esto para tu equipo, el punto de partida honesto es auditar lo que ya están produciendo tus asistentes, no abrir una evaluación de proveedores. Somos Aivy, un equipo de IA y automatización que trabaja con empresas españolas, y en sectores con secreto profesional como los despachos de abogados es el tipo de pregunta que nos gusta mirar contigo. Decidas lo que decidas sobre herramientas, el paso de revisión es el que se paga solo.
Última actualización: julio de 2026. Las puntuaciones corresponden al SCW AI Trust Index publicado en julio de 2026; el índice se mantiene como referencia viva y el ranking cambia según se añaden modelos.
• Secure Code Warrior, AI Trust Index: ranking completo de los 16 modelos (de Claude Sonnet 5 con 80,4 a GPT 5 Mini con 21,6), metodología (11 frameworks, 10 repeticiones, 3 analizadores estáticos, 1.760 codebases), líderes por framework, recuentos de CWE (532: 8.543; 79: 2.949; 798: 1.348) y coste por ejecución (174,94 y 0,58 dólares)
• Technology Decisions: media de 15 vulnerabilidades confirmadas por codebase y 4,3 graves, 86 tipos de CWE distintos, papel de RMIT en la metodología original y declaraciones de Pieter Danhieux
• Endor Labs, AI Coding Agent Security Benchmark: GPT 5.6 Sol 23,5%, Claude Fable 5 29,0%, GPT-5.5 24,0% y 22,4%, GPT-5.4 21,8%; 200 tareas sobre 108 proyectos Python de código abierto y 77 clases de CWE, 17 de julio de 2026
• MITRE CWE-532: definición de la escritura de información sensible en ficheros de log
