El riesgo oculto tras las herramientas gratuitas de IA: Por qué ChatGPT y otras LLM no son seguras

Deja de fingir que tu chatbot es privado

Los equipos de seguridad siguen hablando de "usar ChatGPT con cuidado", como si el principal riesgo fuera que un desarrollador pegue código propietario en un chatbot público. Ese planteamiento está desfasado desde hace años. El verdadero problema es estructural: los grandes modelos lingüísticos (LLM) como ChatGPT, Gemini, Claude y los asistentes de peso abierto no son software determinista. Son sistemas probabilísticos que aprenden de los datos, memorizan patrones y pueden manipularse a través del lenguaje, no parchearse como los binarios. Sólo eso significa que la "seguridad LLM" no es sólo otra lista de comprobación AppSec; es su propio dominio de seguridad. (SentinelOne)

También hay una mentira persistente dentro de las empresas: "Es sólo para brainstorming interno, nadie lo verá". La realidad no está de acuerdo. Los datos internos -notas de auditoría, borradores legales, modelos de amenazas, proyecciones de ingresos- se copian en herramientas de IA públicas o freemium todos los días, sin aprobación de seguridad. Un estudio reciente sobre el uso de la IA en las empresas reveló que los empleados pegan activamente código confidencial, documentos de estrategia interna y datos de clientes en ChatGPT, Microsoft Copilot, Gemini y herramientas similares, a menudo desde cuentas personales o no gestionadas. Los datos corporativos abandonan el entorno a través de HTTPS y aterrizan en una infraestructura que la empresa no posee ni controla. Se trata de una filtración de datos real, no de un riesgo hipotético. (Axios)

Dicho de otro modo: sus ejecutivos creen que están "pidiendo ayuda a un asistente". Lo que en realidad están haciendo es transmitir continuamente inteligencia confidencial a una tubería opaca de computación y registro que usted no puede auditar.

Qué significa realmente "seguridad LLM

La "seguridad LLM" es a menudo malentendida como "bloquear los malos avisos y no hacer jailbreak al modelo". Esa es una pequeña parte. La orientación moderna de los proveedores, los equipos rojos y los investigadores de seguridad en la nube convergen en una definición más amplia: La seguridad LLM es la protección de extremo a extremo del modelo, los datos, la superficie de ejecución y las acciones posteriores que el modelo puede desencadenar. (SentinelOne)

En la práctica, el límite de seguridad abarca:

• Datos de entrenamiento y ajuste. Las muestras envenenadas o malintencionadas pueden implantar un comportamiento "backdoored" que sólo se active bajo determinadas indicaciones elaboradas por el atacante. (SentinelOne)
• Pesos de modelo. El robo, la extracción o la clonación de un modelo perfeccionado filtra la propiedad intelectual, la ventaja competitiva y los datos potencialmente regulados incluidos en la memoria de ese modelo. (SentinelOne)
• Interfaz Prompt. Esto incluye instrucciones al usuario, instrucciones al sistema, contexto de memoria, documentos recuperados y andamiaje de llamadas a herramientas. Los atacantes pueden inyectar instrucciones ocultas en cualquiera de esas capas para anular la política y forzar la fuga de datos. (Fundación OWASP)
• Superficie de acción. Los LLM llaman cada vez más a plugins, API internas, sistemas de facturación, herramientas DevOps, CRM, sistemas financieros, sistemas de tickets. Un modelo comprometido puede desencadenar cambios en el mundo real, no solo un mal texto. (Noticias Hacker)
• Infraestructura de servicio. Esto incluye bases de datos vectoriales, tiempos de ejecución de orquestación, conductos de recuperación y "agentes autónomos". Los sistemas agenéticos heredan los riesgos básicos de LLM, como la inyección puntual o el envenenamiento de datos, y luego amplifican el impacto porque el agente puede actuar. (Inovia)

Wiz y otros investigadores de seguridad en la nube han empezado a describir esto como un "problema de pila completa": Los incidentes de IA se parecen ahora a los compromisos clásicos de la nube (robo de datos, escalada de privilegios, abuso financiero), pero a una velocidad LLM y una superficie LLM. (Knostic)

Los reguladores se están poniendo al día. El Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST) considera ahora el comportamiento adverso de los ML (inyección puntual, envenenamiento de datos, extracción de modelos, exfiltración de modelos) como un problema de seguridad básico en la gestión de riesgos de la IA, no como un tema de investigación especulativo. (Publicaciones del NIST)
Ver: Marco de gestión de riesgos de la IA del NIST y Taxonomía del aprendizaje automático adversarial (NIST AI 100-2e2025).

La incómoda verdad sobre la "gratuidad

Los LLM gratuitos no son organizaciones benéficas. La economía es sencilla: atraer usuarios, recopilar sugerencias de dominio de gran valor, mejorar el producto, convertirlo en una venta adicional para la empresa. Tus indicaciones, tu metodología de búsqueda de errores, tus borradores de informes de incidencias... todo eso es combustible para el modelo de otro. (Cibernoticias)

Según los informes sobre el uso de la IA en el lugar de trabajo, una parte significativa del material sensible que se sube incluye código inédito, lenguaje de cumplimiento interno, lenguaje de negociación legal y contenido de hojas de ruta. En algunos casos, las cargas se realizan a través de cuentas personales para evitar los controles internos, lo que significa que los datos se rigen ahora por la política de retención de otra persona, no por la tuya. (Axios)

Esto es importante por tres razones:

1. Exposición de conformidad. Es posible que esté filtrando datos regulados -datos sanitarios (HIPAA), previsiones financieras (SOX) o información personal de clientes (GDPR/CCPA)- a infraestructuras fuera de sus límites legales. Esto se puede descubrir inmediatamente en una auditoría. (Axios)
2. Riesgo de espionaje empresarial. Los ataques de extracción e inversión de modelos son cada vez mejores. Los atacantes pueden consultar iterativamente un LLM para reconstruir fragmentos de memoria de entrenamiento o lógica propietaria. Esto incluye patrones de código sensibles, credenciales filtradas y reglas de decisión internas. (SentinelOne)
3. Sin límite de retención auditable. Borrar el "historial de chat" en una interfaz de usuario no significa que los datos hayan desaparecido. Muchos proveedores revelan alguna forma de registro y retención a corto plazo (para la supervisión de abusos, mejora de la calidad, etc.), y los plugins/integraciones pueden tener su propio manejo de datos que no puedes ver. (Cibernoticias)
   Ver: El riesgo oculto tras las herramientas gratuitas de IA y SentinelOne sobre los riesgos de seguridad en los LLM.

La versión corta: cuando su vicepresidente pega un modelo de amenaza en un "asistente de IA gratuito", ha creado un procesador externo de su material más sensible, sin contrato, sin DPA y sin SLA de retención.

Diez modos activos de fallo de seguridad LLM que deberías modelar como amenazas

El Top 10 de OWASP para Aplicaciones de Grandes Modelos Lingüísticos y los recientes informes de incidentes de IA convergen en la misma incómoda realidad: Los despliegues de LLM ya están siendo atacados en producción, y los ataques se asignan limpiamente a clases conocidas. (Fundación OWASP)
Ver: OWASP Top 10 para solicitudes LLM.

Esta tabla no es "trabajo futuro". Cada línea ya se ha observado en sistemas de producción a través de SaaS, finanzas, defensa y herramientas de seguridad. (SentinelOne)

La IA en la sombra ya es trabajo de respuesta a incidentes, no teoría

La mayoría de las organizaciones no tienen plena visibilidad de cómo se utiliza la IA internamente. Los empleados piden silenciosamente a los LLM públicos que resuman las auditorías, reescriban las políticas de cumplimiento o redacten las comunicaciones con los clientes. En múltiples casos documentados, se ha pegado documentación confidencial de seguridad interna en ChatGPT o servicios similares desde cuentas personales no gestionadas, lo que ha desencadenado revisiones de incidentes posteriores a los hechos. Esas revisiones consumieron semanas de tiempo forense, no porque hubiera una violación confirmada, sino porque los equipos legales y de seguridad tenían que responder: "¿Acabamos de filtrar datos regulados a un proveedor con el que no tenemos contrato?". (Axios)

Por qué la DLP heredada no puede resolver esto:

• El tráfico a ChatGPT o herramientas similares parece HTTPS cifrado normal.
• La inspección completa y rápida mediante interceptación SSL es legal y políticamente radiactiva en la mayoría de las empresas.
• Aunque fuerces los controles locales del navegador, muchas funciones de IA están ahora integradas en otras herramientas SaaS (editores de documentos, asistentes CRM, resumidores de correo electrónico). Tus usuarios pueden estar filtrando datos a través de "funciones de IA" de las que ni siquiera son conscientes. (Axios)

Este fenómeno suele denominarse "IA en la sombra". Ese nombre es engañoso. Los empleados no están siendo imprudentes; simplemente se están moviendo más rápido que la gobernanza. Trata la IA en la sombra como un SaaS en la sombra, salvo que este SaaS puede memorizarte.

Un libro de jugadas defensivas mínimas para ingenieros de seguridad

Los siguientes controles son factibles con la pila de seguridad actual. No se necesita ciencia ficción.

Tratar los mensajes como entradas no fiables

• Separe las "instrucciones del sistema" (la política y las instrucciones de comportamiento para el modelo) de las entradas del usuario. No permita que las entradas no confiables anulen la política del sistema. Esta es la primera línea de defensa contra la inyección de avisos y las fugas del estilo "ignorar todas las reglas anteriores". (Fundación OWASP)
• Registre y difunda los avisos de alto riesgo para su posterior revisión.

Tratar las respuestas como salida no fiable

• Nunca ejecute directamente SQL generado por el modelo, comandos de shell, pasos de corrección o llamadas a API. Asume que cada salida del modelo está controlada por el atacante hasta que se demuestre lo contrario. OWASP llama a esto Insecure Output Handling, y es un riesgo LLM de primer nivel. (Fundación OWASP)
• Forzar todas las acciones activadas por LLM a través de la aplicación de políticas, sandboxing y allowlists.

Autonomía del modelo de control

• Cualquier agente que pueda modificar la facturación, las configuraciones de producción, los registros de clientes o los datos de identidad/derechos debe requerir la aprobación humana explícita para las acciones de alto impacto. El compromiso de los agentes es multiplicativo: una vez que un agente es dirigido, sigue actuando. (Inovia)
• Las credenciales de alcance por acción, no por agente. Un agente no debe mantener tokens de administración de larga duración.

Vigilar los abusos económicos

• Tokens de límite de velocidad, longitud de contexto e invocaciones de herramientas. OWASP llama la atención sobre el "Modelo de Denegación de Servicio": las peticiones adversamente grandes pueden disparar el coste de la GPU y degradar el servicio ("denial of wallet"). (Fundación OWASP)
• Finanzas debería ver el "gasto de inferencia LLM" como una partida supervisada, de la misma forma que supervisa el ancho de banda saliente.

Para una orientación más profunda, véase:

• Top 10 de OWASP para grandes aplicaciones de modelos lingüísticos
• SentinelOne: Riesgos de seguridad en el LLM
• Marco de gestión de riesgos de la IA del NIST

Ejemplo: envolver un LLM detrás de una capa de políticas y sandbox

El punto del siguiente esquema es simple: nunca confíes en la E/S sin procesar del modelo. Aplica la política antes de llamar al modelo, y aplica un sandbox a cualquier cosa que el modelo quiera ejecutar después.

# Pseudocódigo de una envoltura de seguridad LLM

clase SecurityException(Excepción):
    pass

# (1) Gobernanza de entrada: rechazar intentos obvios de inyección de prompt
def sanitize_prompt(user_prompt: str) -> str:
    frases_prohibidas = [
        "ignorar instrucciones previas",
        "exfiltrar secretos",
        "volcar credenciales",
        "saltarse la seguridad y continuar"
    ]
    lower_p = user_prompt.lower()
    if any(p in lower_p for p in frases_prohibidas):
        raise SecurityException("Se ha detectado una posible inyección del aviso.")
    return mensaje_usuario

# (2) Modelo de llamada con separación estricta sistema/usuario
def llamada_llm(mensaje_sistema: cadena, mensaje_usuario: cadena) -> cadena:
    safe_user_prompt = sanitize_prompt(user_prompt)
    response = model.generate(
        sistema=cierre(sistema_prompt), # rol inmutable del sistema
        user=prompta_usuario_segura,
        max_tokens=512,
        temperatura=0.2,
    )
    devolver respuesta

# (3) Gobernanza de salida: nunca ejecutar a ciegas
def ejecutar_acción(llm_respuesta: str):
    parsed = parse_action(llm_response)

    if parsed.type == "shell":
        # Allowlist-only, inside jailed sandbox container
        si parsed.command no está en ALLOWLIST:
            raise SecurityException("Comando no permitido.")
        return sandbox_run(comando.analizado)

    elif parsed.type == "sql":
        # Sólo consultas parametrizadas de sólo lectura
        return db_readonly_query(parsed.query)

    si no:
        # Texto sin formato, tratado como datos no fiables
        return parsed.content

# Auditoría de cada paso para la defensa forense y normativa
answer = call_llm(SYSTEM_POLICY, user_input)
result = ejecutar_acción(respuesta)
audit_log(entrada_usuario, respuesta, resultado)

Este patrón se alinea directamente con los principales riesgos LLM de OWASP: Inyección de Pruebas (LLM01), Manejo Inseguro de Salidas (LLM02), Envenenamiento de Datos de Entrenamiento (LLM03), Negación de Servicio de Modelos (LLM04), Vulnerabilidades en la Cadena de Suministro (LLM05), Agencia Excesiva (LLM08), y Exceso de Confianza (LLM09). (Fundación OWASP)

Dónde encaja el pentesting automatizado de IA (Penligent)

Llegados a este punto, la "seguridad LLM" deja de sonar a teatro de la gobernanza y empieza a parecerse de nuevo a la seguridad ofensiva. No te limitas a preguntar: "¿Es seguro nuestro modelo?". Tratas de romperlo -de forma controlada- exactamente de la misma manera que probarías una API expuesta o un activo orientado a Internet.

Este es el nicho que Penligente se centra en: pruebas de penetración automatizadas y explicables que tratan los sistemas impulsados por IA (aplicaciones LLM, canalizaciones de generación aumentadas por recuperación, plugins, marcos de agentes, integraciones de DB vectoriales) como superficies de ataque, no como cajas mágicas.

Concretamente, una plataforma como Penligent puede:

• Intente patrones de inyección y jailbreak contra su asistente interno y registre cuáles tienen éxito.
• Explorar si una solicitud no fiable puede engañar a un "agente" interno para que acceda a API privilegiadas, por ejemplo, finanzas, despliegue, emisión de tickets. (Inovia)
• Busque vías de filtración de datos: ¿el modelo pierde memoria de conversaciones previas o de datos de entrenamiento que incluyan información personal, secretos o código fuente? (SentinelOne)
• Simule la "denegación de cartera": ¿puede un atacante disparar su factura de inferencia o saturar su reserva de GPU simplemente alimentando avisos patológicos? (Fundación OWASP)
• Genere un informe respaldado por pruebas en el que se asigne a cada explotación exitosa un impacto empresarial concreto (exposición normativa, potencial de fraude, incremento de costes) y una guía de corrección sobre la que puedan actuar tanto el departamento de ingeniería como la dirección.

Esto es importante porque la mayoría de las organizaciones siguen sin poder responder a preguntas básicas como:

• "¿Puede un aviso externo hacer que nuestro agente interno llame a una API de facturación privilegiada?".
• "¿Puede el modelo filtrar partes de los datos de entrenamiento que se parecen mucho a la información personal del cliente?".
• "¿Puede alguien forzar nuestra factura de GPU para que explote de forma que Finanzas sólo lo note el mes que viene?". (Fundación OWASP)

Las pruebas pentest tradicionales rara vez cubren estos flujos. El pentesting automatizado y consciente de LLM es la forma de convertir la "seguridad LLM" de una diapositiva de política en una prueba real y verificable.

Próximos pasos inmediatos para los ingenieros de seguridad

1. Inventario de puntos de contacto LLM. Clasifica dónde viven los LLM en tu org:
   • SaaS público (cuentas tipo ChatGPT)
   • LLM empresarial" alojado por el proveedor
   • Modelos internos propios o afinados
   • Agentes autónomos conectados a la infraestructura y a CI/CD
     Este es su nuevo mapa de superficie de ataque. (Axios)
2. Tratar los LLM públicos como SaaS externos. "Nada de secretos en herramientas de IA no gestionadas" debe escribirse como política, no como sugerencia. Entrene al personal para que trate las herramientas de IA gratuitas exactamente igual que la publicación en un foro público: una vez que sale, no se controla la retención. (Cibernoticias)
3. Gate acciones de alto impacto detrás de los humanos. Cualquier agente de IA que pueda mover dinero, cambiar configuraciones o destruir registros debe requerir la aprobación humana explícita para los pasos de alto impacto. Asumir el compromiso. Construir para la contención. (Inovia)
4. Hacer que el pentesting compatible con LLM forme parte de la versión. Antes de enviar un "asistente de IA" a clientes o empleados, realice un pase de prueba contradictorio que lo intente:
   • inyectar indicaciones,
   • extraer secretos,
   • escalar los privilegios del plugin,
   • coste del pico.
     Trátalo como tratas los pentests de API externa.

Referencias recomendadas para su libro de jugadas:

• Top 10 de OWASP para grandes aplicaciones de modelos lingüísticos - riesgos específicos de los LLM clasificados por la comunidad (Inyección de instrucciones, Gestión insegura de la salida, Envenenamiento de datos de formación, Denegación de servicio, Cadena de suministro, Agencia excesiva, Dependencia excesiva). (Fundación OWASP)
• Marco de gestión de riesgos de la IA del NIST - formaliza las incitaciones adversarias, la extracción de modelos, el envenenamiento de datos y la exfiltración de modelos como obligaciones de seguridad y no como meras curiosidades de investigación. (Publicaciones del NIST)
• SentinelOne: Riesgos de seguridad en el LLM - Catálogo continuo de técnicas reales de ataque, incluidas la inyección puntual, el envenenamiento de datos de entrenamiento, el compromiso de agentes y el robo de modelos. (SentinelOne)
• El riesgo oculto tras las herramientas gratuitas de IA - la gobernanza de los datos y las realidades de retención del uso libre de la IA en la empresa. (Cibernoticias)
• Penligente - Pruebas de penetración automatizadas diseñadas para infraestructuras de la era de la IA: LLMs, agentes, plugins y superficies de coste.

Conclusión

La seguridad LLM no es higiene opcional. Es respuesta a incidentes, control de costes, protección de la propiedad intelectual, gobernanza de datos y seguridad de la producción, todo a la vez. Tratar ChatGPT como "sólo una herramienta de productividad gratuita" sin modelado de amenazas es el equivalente en 2025 a dejar que los ingenieros envíen credenciales en texto plano por correo electrónico porque "de todos modos es interno". La IA gratuita no es gratis. Se paga en datos, en superficie de ataque y, finalmente, en tiempo de análisis forense. (Cibernoticias)

Si eres responsable de seguridad, ya no puedes decir "no estamos haciendo IA". Tu organización ya lo está haciendo. Su única opción real es si puede demostrar -con pruebas, no con vibraciones- que lo está haciendo de forma segura.