La seguridad del código con IA cambia sobre todo su nivel de control: una herramienta como Copilot, ChatGPT o Claude puede acelerar un desarrollo, pero también puede proponer código vulnerable, dependencias dudosas o una lógica demasiado permisiva. En 2025/2026, Veracode indica que 45 % de las tareas de código generado probadas introducían fallos conocidos. Para un proyecto de pyme, la ganancia de tiempo solo tiene valor si la revisión de seguridad está prevista desde el presupuesto.
Seguridad del código con IA: el verdadero riesgo no es la IA, sino la validación
La intención detrás de una búsqueda sobre la seguridad del código con IA rara vez es académica. Un directivo quiere saber si el uso de herramientas de IA por parte de su proveedor pone en peligro su sitio, su aplicación móvil o los datos de sus clientes. La respuesta corta: no necesariamente, pero solo si el código generado se trata como una propuesta, nunca como una entrega.
Los modelos de lenguaje (LLM, unas IA entrenadas con grandes volúmenes de texto y código) suelen escribir código plausible. Esa es su forza. También es su debilidad. Pueden producir una función que funciona tras una prueba rápida, al tiempo que olvidan el escape de las entradas de usuario, la gestión de permisos o una dependencia mantenida.
Veracode probó más de 100 LLMs en 2025 sobre Java, Python, C# y JavaScript. Su benchmark cubre 80 tareas de codificación y varias categorías CWE, es decir, familias de debilidades de software documentadas, como la inyección SQL CWE-89 o el Cross-Site Scripting CWE-80. El resultado global, confirmado en una actualización de Spring 2026, se mantiene estable: aproximadamente 55 % de código considerado seguro, 45 % vulnerable.
Esta cifra no quiere decir que casi uno de cada dos proyectos vaya a ser pirateado. Dice otra cosa, más útil: sin una consigna de seguridad clara y sin verificación, la IA introduce con demasiada frecuencia errores ya conocidos. Errores banales. Por tanto, evitables.
Lo que los datos recientes dicen a los responsables de decisión
Sonar encuestó a más de 1 100 desarrolladores profesionales en 2026. Según esta encuesta, el código generado o asistido por IA ya representaría 42 % del código subido al repositorio, con una proyección de 65 % en 2027 según los encuestados. En otras palabras, aunque usted no solicite explícitamente IA, es probable que aparezca en la cadena de producción.
El problema no es su uso. Es la diferencia entre desconfianza y disciplina. Sonar recorda que 96 % de los desarrolladores no confían plenamente en el código generado por IA, pero solo 48 % verifican siempre ese código antes de enviarlo al repositorio. Esta contradicción es muy concreta para un presupuesto: una hora ganada al programar puede convertirse en tres horas de corrrección si el fallo se detecta tarde.
Veracode también aporta diferencias por lenguaje. Java muestra 72 % de fallos en las pruebas de seguridad en su muestra, frente a 38 % para Python, 43 % para JavaScript y 45 % para C#. Estos resultados no clasifican los lenguajes del mejor al peor en términos absolutos. Más bien recuerdan que una pila técnica, un framework y unos hábitos de revisión pesan tanto como la herramienta de IA.
| Fuente y año | Indicador | Lo que esto cambia para un proyecto |
|---|---|---|
| Veracode 2025/2026 | 45 % de las tareas de código con IA probadas vulnerables | Prever una revisión de seguridad sistemática, no solo pruebas funcionales |
| Veracode 2025 | XSS/CWE-80 no defendido en 86 % de las muestras afectadas | Verificar la visualización de datos de usuario en las interfaces web |
| Sonar 2026 | 42 % del código subido al repositorio sería generado o asistido por IA | Preguntar cómo la agencia rastrea y relee el código asistido |
| Sonar 2026 | 48 % de los desarrolladores verifican siempre antes del commit | Formalizar la validación en el workflow, no en las intenciones |
| GitHub 2026 | CodeQL/Copilot autofix cubre más del 90 % de los tipos de alertas en JavaScript, TypeScript, Java y Python | Automatizar una parte de la detección, sin sustituir la revisión humana |
Las vulnerabilidades que hay que buscar con prioridad en código generado
Los errores más peligrosos no siempre son espectaculares. Una inyección SQL permite a un atacante desviar una consulta a la base de datos. Un XSS, o Cross-Site Scripting, inyecta script en una página vista por un usuario. Una fuga de información sensible expone una clave API, un token o un dato personal.
OWASP, la referencia comunitaria en seguridad de aplicaciones, enumera en su Top 10 for Large Language Model Applications riesgos relacionados con el uso de los LLMs: mala gestión de las sorties, vulnerabilidades de la cadena de suministro, confianza excesiva, divulgación de informaciones sensibles y autonomía excesiva de los agentes. Estos riesgos también se aplican a los proyectos web clásicos en cuanto un asistente de IA participa en el desarrollo.
Una trampa frecuente está en las dependencias. Una dependencia es un componente de software externo añadido al proyecto, por ejemplo un package npm en JavaScript o una librería Python. Cloudsmith alertó en 2026 sobre los packages alucinados por IA y el “slopsquatting”, una práctica en la que un nombre de paquete plausible o parecido a un paquete real puede conducir a un componente no fiable. Para un no técnico, es invisible en una demostración.
En los proyectos que llevamos a cabo, vemos a menudo la misma disyuntiva: la IA ayuda muy bien a producir código repetitivo, pruebas unitarias o una primera versión de interfaz, pero es menos fiable en cuanto hay que gestionar derechos, pagos, datos personales o la seguridad del servidor. A este nivel, es mejor ir más despacio que corrigir una vulnerabilidad en producción.
La checklist de verificación antes de la puesta en producción
Una buena gobernanza no consiste en prohibir la IA. Consiste en saber dónde se utiliza, en qué partes del código y con qué barreras. Para un directivo, la pregunta que debe plantear al proveedor es sencilla: “¿qué pruebas de control me proporcionan antes de la entrega?”
- Identificar las partes generadas o fortemente asistidas por IA, sobre todo en la autenticación, los formularios, los pagos y la administración.
- Lanzar un análisis SAST (análisis estático del código, sin ejecutar la aplicación) con herramientas como SonarQube, GitHub CodeQL o Semgrep.
- Controlar las dependencias con npm audit, pip-audit, Dependabot, Snyk o un registro de artefactos como Cloudsmith.
- Verificar los secretos: ninguna clave API, ninguna contraseña, ningún token en GitHub, GitLab o Bitbucket.
- Probar las entradas de usuario: formularios, búsqueda, comentarios, subida de archivos, parámetros de URL.
- Revisar los permisos de negocio: un cliente no debe ver los datos de otro cliente, aunque la interfaz no lo muestre.
- Documentar las alertas aceptadas, corrigidas o reportadas, con una razón comprensible para un responsable de toma de decisiones.
GitHub indica en 2026 que CodeQL y Copilot code-scanning autofix cubren más del 90 % de los tipos de alertas en JavaScript, TypeScript, Java y Python, con una corrrección posible de más de dos tercios de las vulnerabilidades supportadas con poca o ninguna edición. Es valioso. Pero una corrrección automática no siempre sabe si una regla de negocio es corrrecta.
Si su proyecto utiliza agentes de IA conectados a sus herramientas, el tema se amplía más allá del código. El Model Context Protocol, o MCP, estandariza por ejemplo la conexión de agentes a datos y servicios; su interés es real, pero los permisos deben estar delimitados, como se explica en nuestro análisis del MCP para conectar los agentes de IA a los datos. Cuanto más puede actuar un agente, más explícitos deben ser sus límites.
Presupuesto, plazos: ¿cuánto cuesta una revisión de seguridad seria?
Un control de seguridad razonable tiene un coste, pero a menudo sigue siendo inferior al coste de un incidente. En Francia, según los proveedores y el tamaño del perímetro, calcule alrededor de 800 a 2 500 € sin IVA para una revisión ligera de un sitio pequeño o de un módulo aplicativo, más bien 3 000 a 8 000 € sin IVA para una auditoría de aplicaciones más completa con análisis del código, dependencias e informe exploitable. Una prueba de intrusión delimitada sobre una aplicación de negocio supera con frecuencia los 5 000 a 15 000 € sin IVA.
El plazo depende del momento en que interviene la revisión. Antes de la puesta en producción, una pasada con herramientas más una relectura específica puede llevar de dos a cinco días laborables en un proyecto de pyme bien organizado. Después de la entrega, con una base de código poco documentada, las mismas comprobaciones pueden duplicarse. Sinceramente, ahorrar esta etapa en una aplicación que maneja datos de clientes no es una buena decisión.
La mejor relaciorn coste/beneficio consiste en integrar los controles en la cadena CI/CD, es decir, el proceso automático que prueba y despliega el software. Un escaneo en cada modificación cuesta poco una vez configurado. Una vulnerabilidad descubierta en el momento de las pruebas de aceptación, en cambio, altera la planificación, el presupuesto y a veces el lanzamiento comercial.
Las obligaciones reglamentarias reforrzaban esta lógica. El RGPD, aplicable desde 2018, impone proteger los datos personales mediante medidas adecuadas. El Cyber Resilience Act europeo también crea nuevas exigencias para determinados software y componentes; para anticipar este marco, puede leer nuestro artículo sobre las obligaciones del Cyber Resilience Act para el software y los plugins. Si su actividad entra en el ámbito de NIS2, la seguridad del sitio o de la aplicación ya no puede tratarse como un complemento tardío; nuestra guía sobre NIS2 aplicada a WordPress desde octubre de 2024 detalla este cambio.
Cuándo la IA acelera de verdad, y cuándo se convierte en una mala elección
La IA es pertinente para generar esqueletos de componentes, proponer pruebas, traducir un fragmento de lógica de un lenguaje a otro o documentar código existente. También puede ayudar a detectar incoherencias simples. En un proyecto con un presupuesto ajustado, es útil si el tiempo ganado financia unas mejores pruebas de aceptación y una mejor seguridad.
La solución evidente se vuelve mala cuando el equipo pide a la IA que produzca deprisa una funcionalidad sensible sin marco. Autenticación, pago Stripe, exportación de datos personales, sincronización con un CRM, back-office de administrador: estas zonas merecen un diseño humano y, después, eventualmente una asistencia de IA bajo supervisión. Un código que “parece funcionar” no es una prueba de seguridad.
La elección técnica también cuenta. Un proyecto JavaScript moderno puede apoyarse en Node.js, Deno o Bun, con modelos de dependencias y de madurez diferentes; este tipo de arbitraje se aborrda en nuestra comparación de los runtimes JavaScript en 2026. En cuanto a la IA alojada, la soberanía y la confidencialidad también cuentan: para las pymes francesas, el uso de herramientas como Mistral debe evaluarse desde la óptica del RGPD, como en nuestra guía sobre Le Chat de Mistral y la protección de datos.
Del lado de la agencia, el reflejo es separar lo que puede acelerarse de lo que debe asegurarse desde el diseño. Esta frontera evita muchos debates inútiles: la IA ni está prohibida ni se acepta en todas partes. Está regulada.
¿Qué exigir a un proveedor que utiliza la IA para programar?
Un proveedor serio no necesita ocultar la IA. Debe explicar cómo la utiliza, cómo revisa, qué herramientas automatizadas hay implantadas y qué límites se han establecido. La transparencia vale más que una vaga promesa de productividad.
Pida un repositorio de código versionado, un historique de validación, un rapport de análisis estático, un estado de las dependencias y una política de gestión de secretos. Si la aplicación trata datos personales, pida también dónde se envían los prompts y los fragmentos de código. El estudio de arXiv publicado en abril de 2026 sobre los debates de seguridad en torno a GitHub Copilot identifica precisamente cuatro preocupaciones recurrentes: fuga de datos, licencias de código, ataques adversariales o prompt injection, y sugerencias de código no seguro.
La seguridad del código IA es, por tanto, menos una cuestión de herramienta que de método. Delimitar este tipo de proyecto de antemano evita la mayoría de las malas sorpresas; a menudo es ahí donde una mirada externa ahorra tiempo, al transformant un riesgo difuso en puntos de control verificables.
Preguntas frecuentes sobre la seguridad del código generado por IA
¿El código generado por IA es siempre menos seguro?
No. Puede ser correcto, sobre todo en tareas simples y bien especificadas. El riesgo viene del hecho de que también puede producir código vulnerable con mucha seguridad, de ahí la necesidad de una revisión sistemática.
¿Qué herramientas utilizar para verificar código de IA?
Los más habituales son SonarQube, GitHub CodeQL, Semgrep, Dependabot, Snyk, npm audit o pip-audit. Detectan vulnerabilidades conocidas, dependencias de riesgo y errores de calidad, pero no sustituyen una revisión funcional.
¿Debería prohibirse ChatGPT o Copilot a los desarrolladores?
En la mayoría de las pymes, la prohibición total es poco realista. Es mejor definir los usos autorizados, excluir los secretos y los datos sensibles de los prompts, y después imponer controles antes de cada integración.
¿Cuánto tiempo añadir al calendario para proteger código IA?
Para un perímetro pequeño, prevea a menudo de dos a cinco días laborables de verificaciones específicas. En una aplicación de negocio con autenticación, roles y datos personales, la revisión debe integrarse a lo largo de todo el desarrollo.