Tu modelo se volvió más listo. Tu código no se volvió más seguro.

La capacidad se acumula. La seguridad se estanca.

Empecemos por lo que de verdad impresiona, porque el argumento no se sostiene si finges que los modelos son malos.

En FrontierBench v0.1, Claude Opus 5 saca un 43,3 % a esfuerzo máximo, frente al 18,7 % de Opus 4.8, el 33,7 % de Fable 5 y el 37,5 % de GPT-5.6 Sol. Entre dos versiones de Opus, la puntuación más que se duplicó. En SWE-bench Verified, Fable 5 anda por el 95 %, y por el 80 % en SWE-bench Pro, el conjunto difícil. Lo que un agente no sabía hacer hace dieciocho meses, hoy probablemente lo hace.

Ahora pon la curva de seguridad en el mismo eje. Varias mediciones independientes, académicas e industriales, dibujan la misma forma: corrección sintáctica por encima del 95 %, éxito en tareas en los ochenta y noventa, y la proporción de código generado que pasa un control de seguridad atascada en mitad de la escala, más o menos donde estaba hace dos años. Las dos líneas se separan.

“

Cada generación de modelo te compra capacidad. Ninguna generación de modelo te ha comprado seguridad.

El motivo no tiene misterio en cuanto miras cómo se entrenan estos modelos. La corrección funcional tiene una señal limpia: los tests pasan o no pasan, el benchmark sube o no sube. Eso se optimiza, con descenso de gradiente y una tabla de clasificación pública. La seguridad no tiene equivalente. Es una propiedad no funcional, cara de etiquetar, en la que la ausencia de vulnerabilidad se parece exactamente a la ausencia de comprobación, y cuyo fallo aparece meses después en un incidente que nadie relaciona con el entrenamiento. La presión de optimización, sea la que sea, no apunta ahí.

Hay una segunda razón, más sutil, visible en los datos de entrenamiento. Algunas clases de vulnerabilidad arrastran décadas de parches documentados y repetidos hasta el infinito en código público: inyección SQL, criptografía débil, path traversal. Los modelos las manejan comparativamente bien, porque el patrón seguro es también el patrón estadísticamente dominante. Las clases que exigen conocer el runtime, el sistema operativo, el modelo de inquilinos o la regla de negocio no tienen ese corpus. No es que estén poco representadas en los datos: no están.

El estado general del problema lo tratamos en ¿es seguro el código generado por IA?. Este artículo va a la pregunta más estrecha y más accionable: dado ese estado, ¿cambiar el modelo o cambiar el prompt hace algo?

Por qué cambiar de modelo no es un control de seguridad

Un modelo más nuevo ayuda un poco, y no donde la gente cree.

Lo que mejora al subir de versión es la capacidad de producir código que funciona, y la capacidad de razonar sobre seguridad cuando se le pregunta directamente. Ese segundo punto merece detenerse, porque ahí se ve el mecanismo del fallo. Los modelos identifican con frecuencia la medida defensiva correcta cuando la planteas como pregunta. Luego escriben el código final y la omiten. La brecha no es de conocimiento, es de ejecución. El modelo no duda sobre si hay que parametrizar una consulta; está optimizando, en el momento de generar, por lo que parece una tarea terminada.

Esa distinción tiene consecuencias comerciales directas, porque predice qué compras te van a decepcionar. Comprar un modelo más listo para reducir la densidad de vulnerabilidades es apostar a la variable equivocada. Obtendrás más código funcional por hora, o sea más código por hora, o sea más de lo que sea tu tasa de vulnerabilidad por hora. Si la tasa es plana y el volumen se triplica, tu exposición absoluta se triplica. Capacidad sin un control equivalente es caudal, y el caudal no es seguridad.

La elección de modelo sí tiene un efecto real, en un solo eje: cuánta carga de verificación cargas tú. Un modelo que acierta las clases de inyección la mayoría de las veces te deja menos que atrapar. Es una ganancia de eficiencia auténtica. No es un control, porque es probabilística, no auditada, y cambia en silencio cada vez que el proveedor publica un nuevo checkpoint.

Por qué decirle al modelo que sea seguro tampoco lo es

Esta es la parte que la mayoría del contenido de fabricantes se salta, incluida, siendo honestos, la versión perezosa de nuestro propio discurso. Si has leído por ahí que basta con meter instrucciones de seguridad en el contexto, los datos no lo respaldan.

La medición más nítida hasta la fecha se titula "An Empirical Evaluation of LLM-Generated Code Security Across Prompting Methods", de Mohammed Kharma, Ahmed Sabbah, Mohammad Alkhanafseh, Mohammad Hammoudeh y David Mohaisen, publicada en arXiv el 22 de mayo de 2026. Cinco LLM, cuatro lenguajes (Java, C++, C y Python), varios métodos de ingeniería de prompts, incluido uno diseñado a propósito para favorecer la tesis de la seguridad: una cadena de pensamiento zero-shot consciente de las debilidades, que enriquece el prompt con contexto de seguridad a partir de mapeos CWE para guiar el razonamiento del modelo.

Su resultado, sostenido por pruebas de chi cuadrado, cabe en una frase del resumen: ninguna reducción estadísticamente significativa en la frecuencia ni en la densidad de vulnerabilidades, con ningún método de prompt. Lo que esas estrategias sí cambian es la composición de las categorías de CWE, con un efecto que varía según el lenguaje. Dicho de otro modo, el prompt consciente de la seguridad reparte de nuevo las cartas de las debilidades que obtienes. No reduce cuántas obtienes.

El hallazgo gemelo es probablemente aún peor para la teoría del prompt como control. "Minimal Prompt Perturbations Lead to Code Vulnerabilities: Prompt Fragility and Hidden-State Signals in Coding LLMs", arXiv, 29 de mayo de 2026, demuestra que modificaciones mínimas y del todo inocuas de un prompt, añadir un comentario, reformular una instrucción, insertar texto inofensivo, devuelven de forma fiable a los modelos de código a generar código vulnerable. No son jailbreaks adversarios. Son retoques corrientes, del tipo que ocurre cien veces al día en una sesión real.

Leídas juntas, esas dos mediciones imponen una restricción de diseño. No puedes poner tu postura de seguridad en el mismo canal que aquello que intentas restringir. Si la política vive en el prompt, compite con la tarea, con las convenciones del repositorio, con el archivo que el agente acaba de leer y con lo que un colaborador escribió en un fichero Markdown. Si la política vive en una barrera que evalúa la acción, no compite con nada.

Qué miden los benchmarks y qué no pueden medir

Antes de sacar conclusiones de cifras de benchmark conviene saber de qué están hechas, porque la lectura honesta es más estrecha que los titulares.

Los benchmarks académicos serios son buenos y van mejorando. CWEval ofrece un benchmark de código multilingüe y crítico en seguridad que abarca 31 tipos de CWE en cinco lenguajes, y su aportación es la evaluación orientada a resultados: juzga funcionalidad y seguridad de forma conjunta en lugar de hacer coincidencia de patrones. RealSec-bench se construye a partir de repositorios Java reales de alto riesgo, 105 instancias en 19 tipos de CWE, un alejamiento deliberado de los fragmentos sintéticos. SecureAgentBench va más allá y evalúa la generación de código seguro en escenarios de vulnerabilidad realistas en vez de prompts aislados.

Los tres comparten tres límites estructurales que ninguna cobertura extra de CWE arregla.

Nada de esto va contra los benchmarks. Va contra tomar una tasa de aprobación por un modelo de riesgo. Un modelo puede liderar todas las tablas de la sección anterior y seguir siendo la causa inmediata de tu próximo incidente, porque tu próximo incidente estará probablemente en la tercera columna de esa rejilla.

Los tres fallos que una subida de versión no toca

En concreto, esto es lo que sigue igual de roto después de pasarte al modelo más nuevo y mejor puntuado que exista.

La lógica de negocio, que no tiene benchmark ni firma

Las clases de vulnerabilidad ricas en parches públicos son las que los modelos manejan mejor. Tus reglas de negocio, en cambio, no tienen ni un parche público, porque existen solo en tu base de código y, con frecuencia, solo en la cabeza de quien las especificó. Un agente capaz de escribir una consulta parametrizada impecable dejará encantado que una cantidad se vuelva negativa si nada en el repositorio le dijo que las cantidades son positivas. Es el fallo que consideramos estructuralmente fuera del alcance de los mejores modelos, y lo documentamos en fallos de lógica de negocio en el código generado por IA.

Las acciones del agente, que son una superficie de ataque aparte

En cuanto el agente puede ejecutar comandos, la pregunta de seguridad deja de ser solo "¿este código es correcto?" y pasa a ser "¿las instrucciones de quién está siguiendo?". Archivos del repositorio como AGENTS.md y CLAUDE.md se cargan como política de proyecto de confianza, lo que los convierte en un canal de dirección para cualquiera que pueda hacer commit. Describimos ese mecanismo y los incidentes con nombre de 2026 en inyección por archivo de instrucciones. Un modelo más capaz empeora esto en vez de mejorarlo, porque ejecuta el plan hostil con más competencia.

Las dependencias que elige

Los modelos siguen inventando nombres de paquetes y los atacantes siguen registrándolos por adelantado. Un modelo mejor alucina menos a menudo, lo que reduce la frecuencia sin cambiar la forma del riesgo, y basta con una alucinación aceptada. Véase qué es el slopsquatting.

Hay que añadir un cuarto punto, aunque no sea un asunto de calidad de código, porque es la prueba más clara de que la capacidad corta por los dos lados. La propia safety card de Anthropic para Opus 5 informa de que el modelo comprometió con éxito redes empresariales en ocho de diez pruebas gubernamentales. En torno a Fable 5, investigadores de Amazon encontraron la manera de que produjera código de demostración de explotación para una vulnerabilidad de software, lo que llevó a Anthropic a redesplegar el modelo con medidas de seguridad reforzadas el 30 de junio de 2026, y el Fable 5 público enruta ahora a otro modelo las detecciones de mal uso ciber, biológico, químico y de destilación. Por separado, informes de la comunidad describen el clasificador de seguridad esquivado en Claude Code al plantear una petición restringida como una pregunta lateral /btw, aprovechando el hueco entre la lógica de enrutado y el contexto principal de la sesión.

Cada uno de esos puntos defiende lo mismo: la frontera avanza a los dos lados de la valla al mismo tiempo. Ninguno defiende quedarse en un modelo viejo. Todos defienden que la barrera esté fuera del modelo.

Subida de versión frente a cumplimiento, lado a lado

La fila que más pesa en una decisión de compra es la segunda. Plano es malo, pero inestable es peor, porque inestable significa que no puedes ni medir tu propia postura. Si un retoque inocuo de un prompt cambia las propiedades de seguridad de la salida, cualquier cifra que produzcas sobre la calidad de tu código generado es la foto de un sistema que mañana será distinto por motivos que nadie registró.

Lo que sí funciona: hacer cumplir en lugar de instruir

Acepta los dos resultados de investigación y el diseño sale casi solo. Si la instrucción no es fiable ni estable, el control tiene que ser algo que actúe, en el momento de la acción, y que pueda rechazar. En la práctica son tres componentes, y vale la pena ser preciso sobre qué hace cada uno, porque la tentación es afirmar que el primero lo hace todo.

Las reglas en el contexto suben el suelo. No lo fijan. Meter las reglas de tu organización y el estado real del repositorio en el contexto del modelo mejora de verdad el primer borrador, y pone tu política por delante de lo que el repositorio afirme. Pero según los datos de arriba, el contexto por sí solo es una mejora probabilística, no una garantía. Quien te diga lo contrario está vendiendo más allá de lo que dice la investigación.

Los hooks son la parte determinista. Un hook evalúa una llamada a herramienta antes de que se ejecute. Leer un archivo de credenciales, mandar un volcado del entorno a curl, lanzar una migración destructiva, invocar una herramienta cuya descripción cambió desde ayer: son eventos discretos e inspeccionables, y una barrera sobre ellos se dispara o no. No la convence un prompt reformulado. Esa es toda la razón de su presencia en el diseño.

Los hallazgos en el bucle eliminan la adivinanza. El agente tiene acceso en vivo a lo que los escáneres encontraron en el código, las dependencias, los secretos, la infraestructura y los pipelines, así que un cambio propuesto se razona contra el estado real del repositorio y no contra una suposición. Eso es también lo que le permite detectar problemas de segundo orden, por ejemplo que el pipeline que le acaban de pedir modificar corre en eventos de fork con permisos de escritura.

El resumen honesto de nuestra posición: el primer componente hace que el modelo se porte mejor la mayoría de las veces, el segundo hace imposible un conjunto concreto de resultados, y el tercero hace que los dos primeros sean exactos. Solo el segundo es un control en sentido estricto. Preferimos decirlo claro antes que insinuar que un prompt es una garantía, porque dos artículos afirman ya lo contrario.

Y el corolario para tu hoja de ruta: este problema no se resuelve esperando. Sea cual sea la puntuación de la próxima versión, cuenta con una curva de seguridad plana y un volumen de código al alza.

Preguntas frecuentes

¿Un modelo más nuevo escribe código más seguro?

Apenas, y no lo suficiente para cambiar tus controles. La corrección funcional mejora mucho entre generaciones mientras la tasa de aprobación en seguridad se queda casi plana. Un modelo más nuevo suele manejar mejor las clases bien documentadas como la inyección SQL o la criptografía débil, porque el patrón seguro es también el patrón común en sus datos de entrenamiento, y no mejora en las clases que exigen conocer tu runtime o tus reglas de negocio. Obtienes más código, con aproximadamente la misma tasa de defectos.

¿Qué modelo escribe el código más seguro?

Las comparativas publicadas sí producen un ranking, y ese ranking se mueve con cada lanzamiento, que es precisamente el motivo para no montar un programa de seguridad encima. La lectura útil de esos estudios es el agregado: la distancia entre el mejor modelo y la media es mucho menor que la distancia entre cualquier modelo y "suficientemente seguro para desplegar sin verificar". Elige un modelo por capacidad y coste, y pon un control delante.

¿Sirve decirle al modelo que escriba código seguro?

No de forma medible, según los datos disponibles. La evaluación de mayo de 2026 de Kharma y sus coautores probó varios métodos de prompt en cinco LLM y cuatro lenguajes, incluida una cadena de pensamiento enriquecida con mapeos CWE, y no encontró reducción estadísticamente significativa en la frecuencia ni en la densidad de vulnerabilidades. El prompt cambió qué categorías de CWE aparecían, no cuántas vulnerabilidades había.

Si el prompt no funciona, ¿para qué sirven las reglas en el contexto del agente?

Para dos cosas que una teoría solo de prompt infravalora. Mejoran el primer borrador, que es una ganancia de eficiencia real aunque sea probabilística, y colocan la política de tu organización en el contexto del modelo por delante de lo que afirme un archivo del repositorio sin revisar. Lo que no pueden hacer es garantizar un resultado. Por eso el hook existe junto a ellas, y por eso no presentamos el contexto como la respuesta completa.

¿Se puede confiar en los benchmarks de seguridad?

Los académicos son rigurosos y van mejorando. CWEval cubre 31 tipos de CWE en cinco lenguajes con evaluación orientada a resultados, RealSec-bench se construye sobre repositorios Java reales de alto riesgo, y SecureAgentBench apunta a escenarios de vulnerabilidad realistas. Sus límites son estructurales más que metodológicos: puntúan una generación única y no sesiones largas de agente, solo pueden probar debilidades con una clase nombrada, y no dicen nada de las acciones del agente frente a su código.

¿Deberíamos quedarnos en un modelo antiguo por seguridad?

No. Los modelos antiguos no son más seguros, solo son menos capaces, así que obtienes la misma tasa de defectos con menos producción. Los riesgos propios de los modelos frontera, un agente que ejecuta un plan hostil con competencia, se abordan restringiendo acciones, no poniendo techo a la capacidad.

¿Significa esto que no se puede desplegar código generado por IA con seguridad?

Sí se puede, a condición de que la verificación y el cumplimiento formen parte del bucle y no de una etapa posterior. El fallo no es "la IA escribe código malo", es "la IA escribe código más rápido que la revisión que debía comprobarlo". Para la versión amplia de ese argumento, mira seguridad de los agentes de código IA.

¿Qué única métrica seguir en lugar de la puntuación de seguridad de un modelo?

Sigue la proporción de acciones inseguras que se rechazaron en vez de revisadas. Una tasa de aprobación te habla del checkpoint de un proveedor. Una tasa de rechazo te habla de tu propio control, se mide en tus logs, y a diferencia de una puntuación de benchmark no se reinicia cuando alguien publica un modelo nuevo.