Claves para gestionar la seguridad en IA generativa al programar

Le pedís a un LLM que te arme una función rápida para autenticar usuarios en SQLite, pegás el código en tu repo y funciona de una. El problema aparece después: ese snippet que te ahorró diez minutos acaba de abrir una inyección SQL directa a producción. La seguridad en IA generativa falla acá de la forma más silenciosa.

El reporte Spring 2026 GenAI Code Security Update de Veracode muestra este problema: cerca del 45% del código generado introduce vulnerabilidades conocidas. En este post te explico de dónde salen estas fallas, qué tradeoffs tenés que evaluar y 6 pasos accionables para blindar a tu equipo el lunes.

El mecanismo del riesgo: generación de código y vulnerabilidades silenciosas

El LLM genera código buscando patrones estadísticos en datasets gigantes con repositorios abiertos, foros y código que ya tenía fallas. No tiene un modelo de amenazas ni analiza riesgos: solo predice qué texto suele venir después. Su lógica es estadística, no de seguridad.

Mirá este caso concreto con SQLite:

import sqlite3

def authenticate_user(username, password):
    conn = sqlite3.connect('users.db')
    cursor = conn.cursor()
    # ¡Vulnerabilidad aquí! Inyección SQL
    query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'"
    cursor.execute(query) # Ejecuta una consulta vulnerable
    user = cursor.fetchone()
    conn.close()
    return user is not None

# Uso (ejemplo)
# if authenticate_user("admin", "password123"):
#     print("Autenticación exitosa")
# else:
#     print("Fallo de autenticación")

El código cumple con lo pedido, pero la línea query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'" tiene una inyección SQL clásica. Si alguien manda admin' -- como usuario, la consulta queda en SELECT * FROM users WHERE username = 'admin' --' AND password = '...'. Los dos guiones anulan el chequeo del password y permiten saltear la autenticación.

El modelo armó esto porque copió patrones repetidos de su entrenamiento. No hay mala intención: solo reproduce lo que parece funcional, dejando fallas graves a la vista de todos.

Tradeoffs en la seguridad de la IA generativa: velocidad vs. riesgos

La IA acelera la escritura de boilerplate, refactors y tests. Si no gestionás el proceso, esa velocidad termina costando caro en seguridad.

Característica	Ganancia (con LLMs)	Pérdida/Riesgo (con LLMs)	Cuándo NO Conviene
Velocidad de Desarrollo	Acelera la generación de código repetitivo, prototipado rápido.	Introduce vulnerabilidades difíciles de detectar, mayor superficie de ataque, deuda técnica de seguridad.	En módulos de criptografía, pasarelas de pago, sistemas de gestión de identidades, o cualquier componente que maneje datos sensibles o lógica de autorización crítica. También, sistemas sujetos a compliance estricto (PCI DSS, HIPAA, GDPR), ya que los LLMs no tienen “memoria” de dichas regulaciones.
Productividad del Dev	Reduce el tiempo en tareas monótonas, permite enfocarse en problemas de mayor nivel.	Requiere mayor esfuerzo en revisión de seguridad, entrenamiento específico en prompt engineering para seguridad, y escaneo constante.	Equipos con poca experiencia en seguridad, sin procesos robustos de revisión de código o donde la trazabilidad y auditabilidad del código son primordiales.
Innovación	Facilita la exploración de nuevas ideas y tecnologías, reduce barreras para experimentar.	Puede generar “innovación” en formas de explotación al crear nuevas combinaciones de vulnerabilidades o configuraciones inseguras que imitan patrones existentes, pero en contextos novedosos.	Proyectos donde la robustez, la confiabilidad y la predictibilidad del comportamiento son más importantes que la velocidad de experimentación, como infraestructuras críticas o sistemas life-critical.

El peligro sube cuando el equipo apurado acepta sugerencias sin revisarlas a fondo. Un análisis de JFrog Security Research sobre CVEs falsos detectó 54 reportes falsos de vulnerabilidades de SQLite generados por IA (de 55 publicados, varios con CVE IDs oficiales). Esto muestra cómo la IA también inventa alertas falsas que consumen tiempo y recursos de los equipos.

El desafío del contexto, la desinformación y las alucinaciones

Un LLM no conoce tu arquitectura, tus estándares internos ni tus requisitos de compliance. Esta falta de contexto genera problemas prácticos inmediatos. Pasa lo mismo cuando le das permisos de ejecución a ciegas, como vimos al analizar cómo evitar que tu agente de IA rompa tu infraestructura.

Por ejemplo, si le pedís un security group de AWS para un servidor web con acceso SSH y HTTP, puede entregarte esto:

{
  "SecurityGroupIngress": [
    {
      "IpProtocol": "tcp",
      "FromPort": 22,
      "ToPort": 22,
      "IpRanges": [
        {
          "CidrIp": "0.0.0.0/0"
        }
      ]
    },
    {
      "IpProtocol": "tcp",
      "FromPort": 80,
      "ToPort": 80,
      "IpRanges": [
        {
          "CidrIp": "0.0.0.0/0"
        }
      ]
    }
  ]
}

El JSON funciona, pero abre SSH y HTTP al mundo entero (0.0.0.0/0) en lugar de limitar SSH a tu VPN o HTTP a tu balanceador interno.

También están las alucinaciones y las prácticas viejas. Si le pedís cómo encriptar datos sensibles en Python, puede devolverte una solución rota:

import hashlib

def encrypt_data_weak(data, key):
    # ¡Vulnerabilidad aquí! Uso de MD5 y clave estática (o débil)
    # MD5 no es un algoritmo de encriptación seguro y no tiene un buen propósito aquí.
    # La clave debería ser gestionada de forma segura.
    hash_object = hashlib.md5(key.encode())
    hashed_key = hash_object.hexdigest()
    # Esto no es encriptación, es un hash. Y MD5 es débil para esto.
    # Además, no maneja IVs ni modos de operación correctos para encriptación real.
    return f"Data:{data}_HashedKey:{hashed_key}"

# Ejemplo de uso (inseguro)
# encrypted_info = encrypt_data_weak("mi_secreto", "clave_secreta_facil")
# print(encrypted_info)

MD5 es una función de hash vieja e insegura para este fin, no un algoritmo de cifrado, y usarlo así debilita el sistema por completo.

graph TD
    A["Desarrollador (prompt)"] --> B{"LLM Genera Código/Config"}
    B -- "Carece de contexto/modelo de riesgos" --> C{"Código Funcional pero Inseguro"}
    C -- "No revisado/Validado adecuadamente" --> D["Vulnerabilidad en Producción"]
    D -- "Explotación" --> E("Brecha de Seguridad")

    subgraph Factores Agravantes
        F["Presión por velocidad"] --> B
        G["Falta de expertise en seguridad"] --> C
        H["Alucinaciones del LLM / Datos de entrenamiento sesgados"] --> B
        I["Confianza ciega en el LLM"] --> C
    end

    subgraph Controles de Mitigación
        J["Prompt Engineering orientado a Seguridad"] --> A
        K["SAST/DAST en CI/CD"] --> C
        L["Revisión de Código por Pares (Enfoque en Seguridad)"] --> C
        M["Políticas de Uso de LLMs"] --> B
        N["Educación y Concientización"] --> A
    end

    K -- "Detecta Vulnerabilidades" --> L
    L -- "Corrige/Refina" --> C

Qué hacer el lunes: pasos accionables para líderes de ingeniería

Podés cuidar la seguridad sin frenar la adopción de estas herramientas en tu equipo. Te recomiendo implementar estos pasos:

Capacitá con casos prácticos: Entrená a tu equipo para detectar fallas comunes con ejemplos claros, como la inyección SQL o las reglas abiertas de firewall. Fomentá una mirada crítica sobre cualquier snippet generado por IA.
Integrá SAST y DAST en tu CI/CD: Configurá escaneos automáticos de código estático y pruebas dinámicas en tiempo de ejecución para aplicaciones web. Podés sumar chequeos automáticos en el pipeline, similar a las prácticas de CI/CD para agentes de IA. El informe de Veracode confirma que estas herramientas son indispensables para frenar fallas antes del deploy.
Reforzá las revisiones de código entre pares: Armá checklists para revisar código asistido por IA. Incluí preguntas concretas: “¿Maneja bien la entrada del usuario?”, “¿Usa librerías criptográficas seguras?”, “¿Deja configuraciones por defecto abiertas?”.
Definí políticas claras y zonas de riesgo: Marcá qué partes del sistema admiten código de IA (como boilerplate de UI) y cuáles exigen supervisión manual estricta (autenticación, autorización o manejo de datos sensibles).
Entrená en prompts orientados a seguridad: En vez de pedir “haceme una función de autenticación”, enseñá a pedir “haceme una función en Python con sentencias preparadas contra inyección SQL, contraseñas hasheadas con bcrypt y rate limiting para intentos fallidos”.
Medí y auditá el código generado: Seguí métricas de calidad como la densidad de fallas detectadas por SAST, los tiempos de review y los bugs de seguridad que lleguen a producción originados por LLMs. Con estos datos vas a poder ajustar políticas y entrenamientos.

El código generado por IA ayuda a acelerar tareas repetitivas, pero no resuelve la seguridad en IA generativa por su cuenta. Tenés que balancear esa velocidad con controles claros para evitar que las fallas lleguen a tus usuarios.