Porque la inteligencia artificial es una herramienta brutal para desarrollar software, pero no puede sustituir a la revisión humana en seguridad, arquitectura y lógica de negocio.
Copiloto, Cursor, Claude, ChatGPT, Gemini… En 2026, cualquier persona con una idea y un prompt puede generar código funcional en minutos. Y funciona. A veces es incluso elegante.
El problema no es que la IA escriba código. El problema es que el código parece correcto. Compila. Pasa macetas básicas. Y esconde vulnerabilidades que nadie ha revisado.
En Undercoverlab usamos IA todos los días. Nos acelera. Permite explorar soluciones más rápido. Pero cada línea que genera pasa por revisión humana. Aquí explicamos por qué.
Los datos: qué dicen los estudios
No estamos hablando de opiniones. Existen estudios recientes con datos contundentes sobre la seguridad del código generado por IA:
| Fuente | Dato clave | Detalle |
|---|---|---|
| Veracode (2025) | 45% del código IA tiene fallas | 100+ modelos testados, 4 lenguajes |
| CodeRabbit (2025) | 1.57x más problemas de seguridad | 2.74x más vulnerabilidades XSS |
| Opsera (2026) | 15-18% más vulnerabilidades | 250.000+ desarrolladores analizados |
| OWASP LLM Top 10 | Prompt inyección, supply chain, data poisoning | Framework de referencia global |
| Georgetown CSET | 40% de Copiloto vulnerable | CWE Top 25 MITRO |
El dato más preocupante: los modelos más grandes y modernos no generan código significativamente más seguro que los antiguos. El problema no se resuelve con más parámetros o mayor entrenamiento. Es estructural.
4 riesgos reales que vemos cada semana
Éstos no son riesgos teóricos. Son problemas que encontramos al auditar código que clientes nos traen después de trabajar con IA sin supervisión:
1. Dependencias desactualizadas con vulnerabilidades conocidas
La IA sugiere paquetes y librerías en base a su entrenamiento, que puede ser de hace meses o años. Esto significa que a menudo recomienda versiones con vulnerabilidades ya documentadas (CVEs). El código funciona, pero estás importando una puerta abierta.
Ejemplo real: Un cliente nos trajo una app generada con IA que usaba una versión de PyTorch con un exploit conocido (Shadow Ray). La aplicación funcionaba perfectamente. También era perfectamente atacable.
2. Inyecciones SQL y XSS sin sanitizar
Según el informe de Veracode, el 86% de las muestras de código generado por IA fallaron ante ataques XSS (cross-site scripting) y el 88% eran vulnerables a inyecciones de log. La IA genera consultas a bases de datos que funcionan, pero no las protege contra entradas maliciosas.
Qué significa esto: Cualquier persona con conocimientos básicos puede manipular un formulario de tu web para acceder a datos que no debería ver, modificarlos o borrarlos.
3. Tokens y claves de API hardcodeados dentro del código
La IA tiende a poner credenciales directamente en el código para simplificar. Si ese código se sube a un repositorio (GitHub, GitLab), tus claves quedan expuestas públicamente. Bots automatizados escanean GitHub constantemente buscando exactamente eso.
Consecuencia: Acceso no autorizado a servicios de pago, bases de datos, servicios cloud. Hemos visto casos en los que un token expuesto ha costado miles de euros en cargos fraudulentos a AWS.
4. Lógica de negocio incorrecta que «funciona»
Éste es quizá el riesgo más sutil. El código compila, pasa tests, la app funciona… pero no hace lo que necesita el negocio. La IA no entiende el contexto de tu negocio. No sabe que ese cálculo de precios debería incluir el IGI andorrano, o que ese workflow de aprobación necesita doble validación por importes superiores a 10.000€.
El código más caro es el que resuelve el problema equivocado.
¿Por qué la IA comete estos errores?
No es que la IA sea «mala». Es que está entrenada para predecir el código más probable, no lo más seguro. Hay una diferencia fundamental:
- Objetivo de la IA: generar código que compile y haga lo que le pidas.
- Objetivo de un desarrollador: generar código que funcione, sea seguro, sea mantenible, escale bien y resuelva el problema correcto.
La IA optimiza por su primera condición. Un desarrollador debe optimizar por las cinco.
Además, los modelos entrenan con código público de GitHub y StackOverflow. Gran parte de ese código no sigue buenas prácticas de seguridad. La IA reproduce los mismos errores que los humanos ya cometían, pero ahora a nivel industrial.
Cómo lo hacemos en Undercoverlab
No somos anti-IA. Lo usamos todos los días. Pero lo usamos como una herramienta en un proceso, no como el proceso entero. Así funciona nuestro workflow:
- Definición de requisitos con el cliente. Antes de tocar código, entendemos el negocio. ¿Qué debe hacer el producto, para quién, con qué restricciones?
- Arquitectura y diseño. Decidimos la estructura, la tecnología y las integraciones. La IA no toma decisiones de arquitectura.
- Desarrollo asistido por IA. Usamos IA para acelerar la generación de código base, tests y documentación. Pero cada output se revisa.
- Revisión de seguridad. Análisis de dependencias, sanitización de inputs, gestión de secretos, validación de lógica de negocio.
- Testing y QA. Tests automatizados + revisión manual de casos límite y edge casas.
- Desarrollo controlado. CI/CD con checks de seguridad automáticos antes de cada despliegue.
La IA participa en el paso 3. Un desarrollador participa en los seis .
Qué deberías hacer si usas IA para tu proyecto
Si estás desarrollando un producto digital y usas IA (directamente oa través de tu equipo), aquí tienes una checklist mínima de seguridad:
- Audita las dependencias — Usa herramientas como Snyk, Dependabot o npm audit para detectar paquetes con vulnerabilidades conocidas.
- Sanitiza todas las entradas — Cualquier input de usuario (formularios, URLs, APIs) debe estar validado y escapado.
- Nunca hardcodejis secretos — Usa variables de entorno y servicios de gestión de secretos (Vault, AWS Secrets Manager, etc.).
- Revisa la lógica de negocio — No confíes en que la IA entienda tu contexto de negocio. Valida manualmente que los cálculos, workflows y reglas sean correctos.
- Implementa code review obligatorio — Ningún código debería llegar a producción sin que un humano lo haya revisado.
- Pon checks de seguridad en el pipeline — Integra SAST/DAST en tu CI/CD para detectar vulnerabilidades antes de cada despliegue.
Conclusión
La IA no es el problema. El problema es confiar en ella sin supervisión.
Un desarrollador no es alguien que escribe código. Es alguien que entiende por qué ese código existe, qué pasa si falla, y cómo protegerlo. Esto no lo hará ningún modelo de lencuaje, por muy avanzado que sea.
Usa la IA. Aprovéchala. Pero pone a un humano en medio.
────────────────────────────────────────
¿Tienes un proyecto digital y quieres asegurarte de que el código está bien?
En Undercoverlab ofrecemos una consulta gratuita de 20 minutos en la que revisamos tu caso y te orientamos sin compromiso.
Escríbenos: hello@undercoverlab.com
────────────────────────────────────────
Fuentes y referencias
- Veracode GenAI Code Security Report (2025) — 45% del código generado por IA contiene fallas de seguridad
- CodeRabbit AI vs Human Code Report (diciembre 2025) — 1.57x más problemas de seguridad en código IA
- Opsera AI Coding Impact Benchmark Report (2026) – 15-18% más vulnerabilidades en código generado por IA
- OWASP Top 10 for LLM Applications (2025) — Framework de riesgos de seguridad en aplicaciones IA
- Georgetown CSET (2024) — 40% de programas generados por Copilot con vulnerabilidades CWE Top 25