Riesgos de la IA Generativa
en la Seguridad del SDLC

Transformer (Vaswani et al., 2017): mecanismo de atención que permite procesar contextos de miles de tokens — base de GPT-4, Codex y LLaMA.
Codex (Chen et al., 2021): entrenado en 54 millones de repos GitHub. Hereda vulnerabilidades del corpus de entrenamiento.
Adopción masiva: 92% de developers lo usan semanalmente (Stack Overflow, 2023) — el riesgo individual se convierte en riesgo organizacional.

La brecha de percepción es el hallazgo más crítico: usar IA puede hacerte sentir más eficiente y seguro, pero la evidencia muestra lo contrario si no hay revisión activa. Este ODC existe para cerrar esa brecha: darte el conocimiento respaldado por 38 estudios científicos para que uses la IA con conciencia real de sus riesgos.

¿Qué es? Detectar y corregir vulnerabilidades cuanto antes en el desarrollo — no al final.
Costo (Seacord, 2013): 1× en desarrollo · 6× en pruebas · 30–100× en producción.
Con IA: el análisis SAST automático en cada commit es el control mínimo para código generado.

SAST (Análisis Estático): SonarQube, Semgrep — revisa el código sin ejecutarlo. Como un corrector que detecta errores antes de publicar.
SCA (Composición de Software): Dependabot — verifica que las dependencias sugeridas por IA no tengan vulnerabilidades conocidas.
DAST (Análisis Dinámico): OWASP ZAP — prueba la app en ejecución en un ambiente seguro.
Secrets scanning: Gitleaks — detecta contraseñas escritas en el código (CWE-798) antes de hacer push.

Amazon CodeWhisperer es la única herramienta que integra análisis de seguridad en tiempo real con referencias directas a CWE, posicionándola como la opción más segura para entornos empresariales. Sin embargo, ninguna herramienta elimina la necesidad de pipeline SAST y revisión humana.

Datos sensibles (salud, finanzas): CodeWhisperer + SAST + revisión manual.
Desarrollo general: Copilot con plugin SonarQube obligatorio en IDE.
Investigación/academia: StarCoder — auditoría completa del entrenamiento.
En todos los casos: nunca deployar código IA sin pipeline de seguridad.

Los modelos de IA aprenden estadísticamente. El código de entrenamiento incluía repositorios públicos con errores de seguridad sin filtrar. El modelo aprende esos patrones inseguros simplemente porque son frecuentes, no porque los identifique como incorrectos. La IA no tiene comprensión de seguridad — solo reproduce lo que aprendió con mayor frecuencia.

Las contraseñas escritas directamente en el código son frecuentes en código de IA porque el modelo fue entrenado con repositorios que contenían archivos de configuración con claves y tokens reales. El modelo los memorizó y los reproduce. A este fenómeno se le llama memorización de datos de entrenamiento, y es la base del problema de privacidad que analizamos en el Módulo 6.

Los datos se agrupan en tres categorías: magnitud del problema (40–50% de código vulnerable), factor humano (brecha de percepción: 47% subestima el riesgo), y soluciones técnicas (SVEN >85% reducción). La convergencia de los 38 estudios confirma que el riesgo es real, documentado y parcialmente mitigable.

Ninguna fase del SDLC está libre de riesgo cuando se usa IA generativa sin controles. La revisión sistemática de Negri-Ribalta et al. (2024) documenta vectores en las 6 fases. La estrategia de mitigación debe ser integral y continua, no puntual — es el fundamento del pipeline DevSecOps del Módulo 2.

Los LLM aprenden repitiendo patrones del código con que se entrenaron. Cuando ese código incluía credenciales o datos personales reales, el modelo los memorizó. Niu et al. (2023) confirmaron esto con pruebas técnicas: Copilot podía reproducir textualmente información de repositorios que después se marcaron como privados en GitHub.
Implicación práctica: si tu empresa compartió código en GitHub antes de usar Copilot, ese código podría aparecer en sugerencias a otros usuarios. Por esto el GDPR y el EU AI Act (Art. 10) exigen transparencia sobre los datos de entrenamiento.

GDPR Art. 25 (Privacy by Design): la seguridad de datos debe integrarse por defecto en el diseño del sistema — incluida la IA generativa.
EU AI Act Art. 10: transparencia sobre datos de entrenamiento y gestión de calidad del corpus.
OWASP LLM01: Prompt Injection como vulnerabilidad crítica #1 en sistemas con LLM.

Ningún control individual es suficiente por sí solo. La estrategia efectiva combina capas complementarias: análisis estático automático (detecta errores antes de compilar), revisión humana (para lo que la herramienta automática no detecta), escaneo de secretos (contraseñas en código), y ajuste fino del modelo (prevención desde el origen). Cada capa cubre lo que las otras no ven.

SVEN (Security Vulnerability Eliminator via fine-tuning): técnica de ajuste fino del modelo LLM creada por He & Vechev (2023). En lugar de detectar errores después de generarlos (como hace SAST), SVEN evita que el modelo los genere desde el principio — re-entrenándolo para penalizar los patrones CWE.
Limitación clave: requiere acceso a los pesos internos del modelo. Solo aplica a modelos open-source (StarCoder, LLaMA) o propios. Para Copilot o GPT-4, el pipeline SAST sigue siendo el control principal disponible.

EU AI Act: lleva un registro de qué herramientas de IA usas en tus proyectos, clasifica el nivel de riesgo y documenta cómo las usas.
NIST AI RMF: integra las funciones de Gobernar y Gestionar en el proceso de aprobación de herramientas de IA en tu equipo.
OWASP LLM Top-10: úsalo como lista de verificación técnica en cada ciclo de desarrollo que incluya IA generativa.

LLM01 (Prompt Injection) → conecta con M3: herramientas con mayor riesgo (ChatGPT).
LLM06 (Info Sensible) → conecta con M6: CodexLeaks y memorización de entrenamiento.
LLM09 (Sobredependencia) → conecta con M1: brecha de percepción de Perry (2023).

Pregunta abierta 1: ¿Qué pasa con los proyectos reales después de un año usando IA? No existen estudios de seguimiento a largo plazo en producción.
Pregunta abierta 2: ¿Cómo afecta esto a equipos latinoamericanos que programan en español? Casi toda la investigación es en inglés y en contextos de EE.UU. o Europa.
Pregunta abierta 3: ¿Cómo comparar herramientas de IA de forma estándar? Aún no existe un marco de evaluación homologado.

Los hallazgos de este ODC abren tres líneas de investigación concretas: estudiar el impacto de la IA en proyectos reales durante meses o años, investigar cómo estos riesgos se manifiestan en equipos latinoamericanos, y desarrollar marcos de evaluación comparativa de herramientas de IA adaptados a nuestro contexto. Estas son oportunidades reales de investigación de posgrado con relevancia local e impacto global.

¿Completaste la evaluación? Necesitas 8/10 correctas (80%) para cumplir el criterio del REA.
¿Quieres repasar? Usa el menú ☰ para volver a cualquier módulo.
¿Citas académicas? Todas las referencias están disponibles en formato APA 7 arriba.