El desarrollo de software avanza ahora más rápido de lo que la mayoría de los programas de seguridad pueden asimilar. Las herramientas de programación con IA están ayudando a los equipos a escribir y confirmar código más rápido, pero las investigaciones de 2025 y 2026 de GitLab, Veracode y Checkmarx apuntan al mismo problema: la gobernanza, las pruebas y la propiedad del código se están quedando atrás. Si publicas código asistido por IA, la respuesta práctica es contundente: trátalo como no fiable hasta que haya sido revisado, analizado y trazado.
El desarrollo de software ha superado sus barreras de seguridad
La intención de búsqueda aquí es informativa con un enfoque práctico: quieres entender qué ha cambiado en el desarrollo de software, por qué los equipos de seguridad están preocupados y cómo es una respuesta sensata sin ralentizar la ingeniería hasta el extremo. La respuesta incómoda es que la velocidad en sí no es el enemigo. La velocidad no verificada sí lo es.
El AI Accountability Report 2026 de GitLab, publicado el 23 de junio de 2026, encuestó a 1,528 desarrolladores y compradores de tecnología en seis países. Descubrió que 91% de las organizaciones tenían dos o más herramientas de programación con IA en uso activo, mientras que 78% dijo que los desarrolladores escriben o confirman código más rápido. Esto coincide con lo que muchos responsables de ingeniería ya perciben: las pull requests llegan antes, los prototipos parecen terminados antes y las estimaciones del backlog son cada vez menos precisas.
La gobernanza no siguió el ritmo. En el mismo informe de GitLab, 80% dijo que las herramientas de IA se adoptaron más rápido que las políticas de gobernanza, y 92% informó de desafíos de gobernanza con el código generado por IA. No se trata de una pequeña brecha de proceso. Es un desajuste estructural entre la rapidez con la que ahora se puede producir código y la lentitud con la que la mayoría de las organizaciones siguen aprobándolo, probándolo, auditándolo y documentándolo.
Para una visión más amplia de cómo la IA está cambiando el trabajo de ingeniería, el cambio también es visible en las competencias de calidad en ingeniería bajo la presión de la IA. La prima de las habilidades se está desplazando de teclear código hacia formular mejores preguntas, revisar resultados poco familiares y detectar el tipo de riesgo sutil que parece inofensivo en una compilación exitosa.
Las cifras son demasiado coherentes como para descartarlas
Un estudio puede ser irregular. Varios estudios que apuntan en la misma dirección merecen atención. La Developer Survey 2025 de Stack Overflow informó de que 84% de los encuestados estaban usando o planeaban usar herramientas de IA en su proceso de desarrollo, frente al 76% del año anterior. La Global DevSecOps Survey 2026 de GitLab, que abarcó a 3,266 profesionales, indicó que la mezcla actual de fuentes de código era de 34% generado por IA, 37% escrito desde cero y 29% copiado de otras fuentes.
La señal de seguridad es igual de clara. El GenAI Code Security Report 2025 de Veracode probó más de 100 modelos de lenguaje de gran tamaño en Java, Python, C# y JavaScript. Según Veracode, 45% de las muestras de código generadas por IA no superaron las pruebas de seguridad e introdujeron vulnerabilidades del OWASP Top 10. Java obtuvo el peor resultado en esas pruebas, con una tasa de fallo de seguridad de 72% en todas las tareas.
Checkmarx añadió una perspectiva de riesgo en producción en junio de 2026. Su informe Future of Application Security 2026 encuestó a 2,350 CISOs, responsables de AppSec y desarrolladores de 14 países entre el 10 y el 30 de marzo de 2026. La empresa informó de que las organizaciones con entre 81% y 100% de código de producción generado por IA tenían casi tres veces más probabilidades de lanzar software con vulnerabilidades conocidas que aquellas con entre 1% y 20% de código de producción generado por IA, citando 47% para el grupo con alto uso de código de IA.
| Fuente | Año | Alcance | Encontrar |
|---|---|---|---|
| AI Accountability Report de GitLab | 2026 | 1,528 desarrolladores y compradores de tecnología | 91% de las organizaciones utilizaban dos o más herramientas de programación con IA |
| Global DevSecOps Survey de GitLab | 2026 | 3,266 profesionales de DevSecOps | Se informó de que 34% del código era generado por IA |
| Developer Survey de Stack Overflow | 2025 | Desarrolladores encuestados | 84% usó o planeó usar herramientas de IA en el desarrollo |
| Informe de seguridad del código GenAI de Veracode | 2025 | 100+ LLMs, cuatro idiomas | 45% de las muestras generadas por IA no superaron las pruebas de seguridad |
| Futuro de AppSec de Checkmarx | 2026 | 2,350 profesionales de seguridad y desarrollo | Las empresas con un alto uso de código de IA tenían casi 3 veces más probabilidades de enviar software con vulnerabilidades conocidas |
Un cálculo concreto facilita ver el riesgo. Si un equipo fusiona 200 cambios asistidos por IA en un trimestre y la tasa de fallos de Veracode 2025 de 45% fuera siquiera aplicable de forma orientativa, 90 cambios merecerían una revisión de seguridad antes de pasar a producción. El número exacto en tu base de código será distinto. La implicación en la carga de trabajo no lo será.
Por qué el código generado por IA es más difícil de gobernar
El desarrollo de software tradicional dejaba huellas. A menudo se podía saber si un bloque procedía de un ingeniero sénior, de una respuesta de Stack Overflow, de un SDK de un proveedor o de un copia y pega apresurado de un proyecto anterior. La IA difumina esa procedencia. GitLab informó en 2026 de que 43% de los encuestados no podían distinguir de forma fiable el código generado por IA del código escrito por humanos en su propia base de código.
La mantenibilidad es el impuesto oculto. En la misma publicación de GitLab, a 73% le preocupaba la mantenibilidad, y 82% dijo que el código generado por IA corre el riesgo de crear nueva deuda técnica. Esto encaja con lo que ven los buenos revisores: el código generado puede estar sintácticamente ordenado y, aun así, repetir patrones antiguos, añadir abstracciones innecesarias o resolver con mucha seguridad el problema equivocado.
La trampa de la que nadie habla lo suficiente es la alucinación de dependencias. Un modelo puede sugerir un nombre de paquete que parece plausible, o incorporar una biblioteca abandonada porque aparecía en datos de entrenamiento antiguos. El resumen del Informe de gestión de artefactos 2026 de Cloudsmith afirmaba que la aplicación media contiene ahora más de 1,200 dependencias, y su página del seminario web de 2026 informó de que solo 17% de las organizaciones tenían barreras automatizadas para riesgos específicos de la IA, como pesos de modelos maliciosos o dependencias alucinadas. Aunque consideres esas cifras de Cloudsmith como señales de una sola fuente, la dirección es aleccionadora.
La exposición de la cadena de suministro también se amplía cuando los agentes de programación pueden leer repositorios, proponer cambios, ejecutar comandos o descargar paquetes. La asociación de abril de 2026 de Cursor con Chainguard, de la que informó Axios, es una señal de mercado útil: los proveedores serios de herramientas de programación saben que el código open source vulnerable o malicioso ya forma parte del problema de la programación con IA, no es una cuestión aparte.
La seguridad debe desplazarse a la izquierda, pero no a ciegas
Adelantar la seguridad en el desarrollo de software ha sido un buen consejo durante años. Con la programación con IA, se convierte en un consejo incompleto. Las comprobaciones tempranas ayudan, pero no resuelven el problema si el código generado por el modelo lo revisa la misma persona que lo solicitó, bajo la misma presión de entrega y con los mismos puntos ciegos.
Un patrón mejor es la desconfianza por capas. El código generado debería someterse a análisis estático, escaneo de dependencias, detección de secretos, análisis de composición de software y revisión humana centrada en el comportamiento más que en el estilo. Si estás usando agentes que interactúan con herramientas o con contexto externo, el modelo de amenazas también empieza a solaparse con ataques de inyección de prompts contra sistemas automatizados.
Algunos equipos se sentirán tentados de resolver esto con más revisión mediante IA. Eso es útil, pero solo hasta cierto punto. El agente de revisión puede detectar validación de entradas ausente o un patrón SQL arriesgado, pero también puede compartir supuestos con el generador. Los revisores humanos siguen siendo los más importantes cuando entran en juego la lógica de negocio, los límites de autorización y los casos de abuso.
Para los equipos que ya están experimentando con flujos de trabajo agénticos, la revisión de código con IA puede reducir la fatiga de los revisores, pero no debería convertirse en un mero trámite. Sinceramente, esto solo tiene sentido si el revisor de IA se trata como una señal entre varias, no como la autoridad final antes de la fusión.
Una lista práctica de comprobación de seguridad para equipos asistidos por IA
El objetivo no es prohibir la IA en el desarrollo de software. Eso sería algo performativo en muchas organizaciones y se ignoraría en el resto. La mejor opción es hacer que el camino seguro sea el más rápido, para que los desarrolladores no tengan que elegir entre entregar y cumplir la política.
- Etiqueta los cambios asistidos por IA en las pull requests. No necesitas una letra escarlata, pero los revisores deberían saber cuándo hay código generado, pruebas generadas o refactorizaciones hechas por agentes.
- Exige comprobaciones de procedencia de las dependencias. Los paquetes nuevos deberían verificarse con registros de confianza, mantenimiento activo, política de licencias y bases de datos de vulnerabilidades conocidas antes de la fusión.
- Ejecuta pruebas de seguridad antes de la revisión humana. El análisis estático, el SCA, el escaneo de secretos y las comprobaciones de IaC deberían comentar directamente en la pull request, no aparecer días después en un panel que nadie abre.
- Revisa manualmente la autorización y el tratamiento de datos. Las herramientas de IA suelen ser buenas con el código repetitivo y malas con tus límites de confianza específicos.
- Mide los defectos escapados por fuente del código. Si no haces seguimiento de si los incidentes procedían de código generado por IA, copiado o escrito por humanos, estás debatiendo sensaciones en lugar de evidencias.
El contexto del repositorio importa aquí. Las herramientas que entienden la arquitectura, la propiedad y los incidentes pasados son más útiles que el autocompletado con confianza. Por eso inteligencia de repositorios para programación con AI se está convirtiendo en una categoría seria en lugar de una funcionalidad opcional.
Los permisos de los agentes merecen especial cuidado. Si tu asistente de programación puede abrir tickets, modificar archivos, llamar a sistemas de compilación o interactuar con APIs internas, ya no estás tratando con una simple sugerencia de código. Estás tratando con una capacidad delegada, y el modelo de seguridad empieza a parecerse más a las preocupaciones tratadas en prácticas de seguridad del servidor MCP.
La incómoda disyuntiva: velocidad frente a responsabilidad
¿Puede seguir siendo seguro un desarrollo de software más rápido? Sí, pero solo si la responsabilidad también se acelera. La seguridad no puede seguir siendo una ceremonia de última fase cuando el código se está generando, editando y fusionando a ritmo de máquina.
También hay un problema cultural. The Register resumió una investigación de Checkmarx en junio de 2026 concluyendo que 70% de los desarrolladores creen que el código generado por IA tiene más vulnerabilidades y que 30% envían conscientemente código vulnerable a producción. Tómalo como una cobertura secundaria citada, no como un extracto de una encuesta primaria, pero el comportamiento que describe resulta familiar: los plazos vencen a la incomodidad.
El contraargumento merece atención. La IA puede mejorar la seguridad cuando se usa bien. Puede generar pruebas, explicar rutas de código desconocidas, identificar validaciones ausentes y ayudar a los desarrolladores junior a comprender más rápido patrones seguros. Las herramientas nativas de terminal y los agentes de programación, como los comparados en flujos de trabajo de programación con IA en terminal, pueden ser muy productivos cuando se combinan con permisos estrictos y comprobaciones repetibles.
Aun así, las ganancias de productividad no se traducen automáticamente en ganancias de calidad. En el desarrollo de software, el código que llega más rápido sigue teniendo que ser asumido por alguien. Si nadie puede explicar por qué existe una función, en qué datos confía y cómo falla, la organización no ha ganado capacidad de ingeniería. Ha alquilado incertidumbre.
Lo que harán a continuación los buenos equipos
Los equipos más sólidos no discutirán si la IA tiene cabida en el desarrollo de software. Darán por hecho que ya está ahí y construirán controles en torno a esa realidad. El uso de IA en la sombra, los fragmentos copiados, las pruebas generadas por modelos y las pull requests escritas por agentes necesitan todos lo mismo: trazabilidad.
Empieza con una política que los desarrolladores realmente puedan seguir. Un estándar de programación con IA de dos páginas es mejor que un PDF de 40 páginas que aprobó el departamento legal y que los ingenieros ignoran. Especifica qué herramientas están permitidas, qué datos pueden pegarse en ellas, cuándo debe revelarse el uso de IA y qué rutas de código requieren revisión humana de seguridad independientemente del estado de las pruebas.
Después, pon cifras en el panel de control. Haz seguimiento de las pull requests asistidas por IA, los hallazgos de seguridad por cada mil líneas modificadas, las incorporaciones de dependencias, los paquetes vulnerables bloqueados antes de la fusión y los defectos posteriores al lanzamiento vinculados al origen del código. A lo largo de unos pocos trimestres, verás si la IA está ayudando a tu proceso de desarrollo de software o simplemente está acelerando el desorden.
Mi opinión: los ganadores no serán los equipos que generen más código. Serán los equipos que eliminen más código malo, entiendan mejor el código restante y se nieguen a confundir velocidad con progreso.
Preguntas frecuentes
¿Es el código generado por AI menos seguro que el código escrito por humanos?
Puede serlo. Veracode informó en 2025 de que 45% de las muestras de código generadas por IA analizadas no superaron las pruebas de seguridad, mientras que Checkmarx informó en 2026 de que un uso más intensivo de código de IA se correlacionaba con una mayor probabilidad de lanzar software con vulnerabilidades conocidas.
¿Deberían las empresas prohibir las herramientas de IA en el desarrollo de software?
Una prohibición total suele ser poco realista. Un enfoque más seguro consiste en usar herramientas aprobadas, normas claras de divulgación, análisis automatizados, controles de dependencias y revisión humana obligatoria para las rutas de código sensibles.
¿Cuál es el mayor riesgo de las herramientas de codificación de IA?
El mayor riesgo es que entre en producción código no rastreable. Si no puedes saber si el código ha sido generado por IA, copiado o escrito a mano, tampoco puedes medir su tasa de defectos ni asignar una responsabilidad significativa.
¿Cómo pueden los desarrolladores usar de forma segura las herramientas de programación con IA?
Úsalos para borradores, pruebas, refactorizaciones y explicaciones, pero verifica cada cambio sensible para la seguridad. Trata el código generado como una pull request de un desconocido bienintencionado: útil, a veces impresionante, y nunca fiable por defecto.
ES 
EN 
FR