El 28 de julio de 2026, Veracode publicó su 2026 GenAI Code Security Report. La tasa de aprobación de seguridad del código generado por inteligencia artificial quedó en 56%, apenas distinta del 55% del primer informe de 2025. La medición se realizó sobre las mismas tareas sensibles a seguridad en Java, JavaScript, C# y Python, con más de 100 modelos evaluados desde el inicio del programa. El código generado aprueba las pruebas de cross-site scripting solo el 15% de las veces y las de log injection el 12%.
El dato contradice una expectativa común: que modelos más potentes producen código más seguro. No es lo que muestran los números. La seguridad del código generado no mejora con la capacidad del modelo porque el problema no está en la generación, sino en los datos de entrenamiento y en la ausencia de un circuito de revisión que deje evidencia auditable.
Qué pasó
Veracode mantiene un programa continuo de evaluación de código generado por IA desde 2025. El informe de 2026 confirma que la tasa de aprobación de seguridad no se mueve: 56% frente al 55% del año anterior. La diferencia de un punto porcentual no es estadísticamente significativa sobre el mismo conjunto de tareas y lenguajes.
El detalle por tipo de vulnerabilidad es más revelador que el promedio. Cross-site scripting: 15% de aprobación. Log injection: 12%. Estos números indican que el modelo no entiende el contexto de seguridad de lo que genera. Produce código funcional que falla sistemáticamente en controles básicos de validación de entrada y manejo de datos no confiables.
Lo que el modelo no aprende
Un modelo de lenguaje aprende de repositorios públicos, foros, documentación y ejemplos. Ese corpus contiene código vulnerable en proporciones masivas. El modelo aprende a replicar patrones, no a distinguir patrones seguros de inseguros. Cuando se le pide una función que procese entrada de usuario, el modelo recupera el patrón estadísticamente más probable, no el más seguro.
El informe de Veracode lo confirma indirectamente: más de 100 modelos evaluados, y la tasa de aprobación no mejora con la escala ni con la arquitectura. El problema es el dato de entrenamiento, no la capacidad generativa.
Por qué la seguridad del código no mejora aunque el modelo mejore
La generación de código por IA funciona por predicción estadística. El modelo predice el siguiente token más probable dado el contexto. Si en los datos de entrenamiento la función que sanitiza entrada aparece en el 15% de los casos y la que no sanitiza en el 85%, el modelo generará la versión sin sanitizar con mayor probabilidad, independientemente de cuántos parámetros tenga.
Agregar más parámetros o más capas de atención no corrige este sesgo. Lo amplifica. Un modelo más potente aprende mejor la distribución de los datos de entrenamiento, incluida la distribución de vulnerabilidades. Genera código inseguro con mayor fluidez y coherencia, no con mayor seguridad.
El segundo factor es la ausencia de retroalimentación de seguridad en el ciclo de generación. El modelo no ejecuta el código, no lo pasa por un analizador estático, no recibe señales de un entorno real. Genera y termina. La seguridad queda como responsabilidad exclusiva de quien usa la salida del modelo.
El riesgo en entornos que alguien audita
En un entorno regulado, cada cambio en producción debe tener una persona identificable que lo revisó y aprobó. El supervisor no audita el código: audita la evidencia de que alguien competente lo revisó. Cuando el código lo genera una IA, esa evidencia debe ser más sólida, no menos.
El problema no es usar IA para generar código. El problema es no poder demostrar que ese código pasó por un proceso de revisión equivalente al del código escrito por una persona. Si el revisor confía en que el modelo produce código seguro porque es un modelo avanzado, está delegando su criterio profesional en una distribución estadística que falla el 44% de las veces.
Impacto para empresas en Panamá y LATAM
La Ley 81 de 2019 de protección de datos personales en Panamá exige medidas de seguridad proporcionales al riesgo. No menciona inteligencia artificial, pero su principio de responsabilidad es directo: quien trata datos personales debe poder demostrar que tomó medidas adecuadas para protegerlos.
Si una organización financiera panameña despliega código generado por IA que procesa datos personales y no puede mostrar quién lo revisó, con qué criterios y con qué resultado de análisis de seguridad, está en incumplimiento. El regulador no necesita una norma específica sobre IA: necesita evidencia de que existió diligencia.
En el resto de LATAM, el patrón regulatorio es similar. Las normas de protección de datos y las circulares de los supervisores financieros exigen trazabilidad de cambios, segregación de funciones y revisión por pares. El código generado por IA no está exento de estos requisitos. Al contrario: su naturaleza automatizada exige controles compensatorios más estrictos.
El auditor asume que una persona identificable revisó y aprobó cada cambio en producción. Esa presunción no cambia porque la herramienta que generó el código sea un modelo de lenguaje. Si la organización no puede probar la revisión, el auditor concluye que no existió.
Qué puede hacer su empresa hoy
-
Registrar la procedencia de cada cambio generado por IA. Todo commit o pull request que contenga código generado por una herramienta debe incluir metadatos explícitos: qué herramienta lo produjo, qué modelo, qué prompt se usó. Sin esto, la trazabilidad se rompe en el primer eslabón. El registro de procedencia es el equivalente a anotar quién escribió el código, pero para una fuente no humana.
-
Asignar un revisor identificable y registrar su nombre en la plataforma. La revisión no puede ser anónima ni automatizada. Una persona con nombre, rol y competencia demostrable debe aprobar el cambio. La plataforma de control de versiones o de gestión de cambios debe conservar ese registro de forma inmutable. El auditor buscará ese nombre.
-
Ejecutar análisis estático de seguridad sobre cada cambio y archivar el resultado. El análisis debe correr sobre el código generado antes de que llegue a producción. El resultado —aprobado, rechazado, hallazgos— debe archivarse junto con el cambio. No basta con ejecutar el análisis: hay que conservar la evidencia de que se ejecutó y cuál fue el resultado. Esto aplica a vulnerabilidades como cross-site scripting y log injection, donde el informe de Veracode muestra tasas de fallo del 85% y 88% respectivamente.
-
Definir criterios de aceptación con requisitos de seguridad explícitos. No alcanza con que el código funcione. Los criterios deben incluir condiciones verificables: ausencia de vulnerabilidades de severidad alta o crítica en el análisis estático, validación de todas las entradas de usuario, manejo explícito de errores sin fuga de información. Estos criterios deben estar escritos y asociados al cambio.
-
Documentar excepciones con quién las autorizó y por qué. Si un hallazgo de seguridad no se corrige antes de producción, debe existir un registro de excepción: qué hallazgo, por qué se acepta el riesgo, quién lo autorizó y hasta cuándo. Sin este registro, cualquier vulnerabilidad en producción es un hallazgo de auditoría sin defensa posible. La excepción documentada transforma un riesgo no mitigado en un riesgo aceptado conscientemente.
Estas cinco acciones no dependen de una herramienta específica. Dependen de procesos y disciplina de registro. El análisis de la cadena de suministro de herramientas de IA muestra que el riesgo no está solo en el código generado, sino en cada eslabón de dependencias. Un programa de gestión de superficie de ataque de aplicaciones integra estos controles en un ciclo continuo.
Mi perspectiva
Uso Claude Code a diario para construir automatizaciones. En mi equipo, todo cambio generado por una herramienta lleva registro de procedencia: herramienta, modelo y persona que lo revisó. No es una carga adicional: es la única forma de que el código generado sea auditable.
El dato de Veracode —56% de aprobación, sin mejora en un año— me dice que el modelo no va a resolver la seguridad por sí solo. La responsabilidad sigue donde siempre estuvo: en quien revisa, aprueba y despliega. La diferencia es que ahora hay que documentarlo con más rigor, porque el código no tiene un autor humano que se haga cargo.
En entornos regulados de Panamá y LATAM, la pregunta del auditor no es si usamos IA. Es si podemos mostrar quién revisó cada cambio y con qué evidencia. Si no podemos responder eso, el resto de la conversación no importa.
Preguntas frecuentes
¿Por qué la seguridad del código generado por IA no mejora con modelos más avanzados?
El informe 2026 de Veracode muestra que la tasa de aprobación de seguridad se mantiene en 56%, prácticamente igual al 55% de 2025. El problema no está en la potencia del modelo, sino en que los datos de entrenamiento contienen patrones inseguros que el modelo replica con fidelidad. Un modelo más grande que aprende de código vulnerable simplemente genera vulnerabilidades con mejor sintaxis.
¿Qué evidencia necesita un auditor cuando se usa código generado por IA?
Un auditor necesita cinco registros trazables: procedencia del cambio con herramienta y modelo, revisor identificado, resultado del análisis estático archivado, criterios de aceptación con requisitos de seguridad explícitos, y excepciones documentadas con autorización. Sin estos cinco elementos, el código generado por IA es una caja negra que ningún supervisor puede validar.
¿Aplica la Ley 81 de 2019 de Panamá al código generado por inteligencia artificial?
Sí. La Ley 81 exige medidas de seguridad proporcionales al riesgo sobre los datos personales. Si una organización despliega código generado por IA sin revisión demostrable y ese código procesa datos personales, está incumpliendo el principio de responsabilidad. El regulador no pregunta qué herramienta generó el código: pregunta quién lo revisó y qué evidencia existe.