¿Qué es la seguridad de los LLM? Cómo mitigar los 10 principales riesgos de seguridad de OWASP

Un ataque que engaña a una IA para que trate las instrucciones de un atacante como órdenes —la inyección de prompts— ha ocupado el número 1 del OWASP Top 10 para aplicaciones de LLM en todas las ediciones desde 2023.

La lista es lo más parecido a un consenso que existe en la seguridad de la IA. El proyecto empezó como un pequeño grupo de profesionales de la seguridad y hoy cuenta con más de 600 expertos colaboradores en más de 18 países.

Somos una empresa de IA que publica una guía sobre cómo se puede convencer a la IA de hacer cosas, así que no vamos a fingir que el problema está resuelto. Wilson, que codirige el proyecto de OWASP, fue bastante claro sobre las defensas actuales: «...francamente, no creo que estemos al 99 %».

La edición de 2026 empieza en la misma línea. El responsable del proyecto nos pide que «dejemos de intentar construir un modelo al que no se pueda engañar» y que diseñemos el sistema que lo rodea para que un modelo engañado no pueda romper nada importante.

Aplicamos ese enfoque a los 10 riesgos de la lista de OWASP de 2026.

¿Qué significa la seguridad de los LLM?

La seguridad de los LLM consiste en proteger los modelos de IA y las aplicaciones que los utilizan frente a ataques y usos indebidos. El riesgo aumenta en función de aquello a lo que está conectado el modelo: los archivos y datos que puede leer, y las herramientas que puede usar, como el correo electrónico, la búsqueda o la base de datos de una empresa.

En un software bien protegido, hay una línea clara entre las instrucciones que sigue un programa y la información que procesa. Pero los LLM no tienen esa línea.

Todo lo que lee el modelo le llega como un único flujo continuo de texto: las instrucciones del desarrollador, tu pregunta, una página web que ha consultado. Se supone que los modelos de IA deben saber quién está hablando en cada momento, ya sea el desarrollador, el usuario o el propio modelo razonando sobre un problema.

Pero los investigadores Jasmine Cui y Charles Ye descubrieron que los modelos suelen adivinar quién habla por cómo suena el texto. Así que, si un atacante escribe algo que suena como el razonamiento del propio modelo, este puede creer que la idea se le ocurrió a él. Eso es un problema para cualquier sistema de seguridad que dependa de que el modelo sepa quién manda.

Nos hemos encontrado con el mismo problema en nuestros propios agentes de IA. Nuestro CISO, Kyle Polley, dijo a ISMG que los agentes «podrían no seguir las políticas aunque las añadas al prompt del sistema». Por eso creamos Numbat, una herramienta de código abierto que comprueba lo que un agente está a punto de hacer y puede bloquearlo si la acción incumple una regla de seguridad configurada.

La seguridad de los LLM implica aceptar que el modelo a veces obedecerá a quien no debe, y rodearlo de barreras de protección de IA que sigan funcionando cuando eso ocurra.

¿Cuáles son las prácticas recomendadas de seguridad para LLM?

Repasaremos el OWASP Top 10 para aplicaciones de LLM 2026 en orden, del n.º 1 al n.º 10.

Para cada riesgo, encontrarás una explicación en lenguaje sencillo de cómo pueden torcerse las cosas y un ejemplo real. Después, veremos las prácticas que pueden ayudar a evitarlo o, como mínimo, a limitar los daños.

1. Contén la inyección de prompts

Una inyección de prompts se produce cuando un atacante consigue que una IA siga instrucciones que no debería. Esas instrucciones pueden llegar directamente en un chat o estar ocultas en un correo electrónico, una página web o un documento.

El segundo tipo se conoce como inyección de prompts indirecta. Le pides a tu asistente que resuma un documento. En él, alguien le ha ordenado al asistente que le envíe tus archivos privados. Si el asistente sigue esas instrucciones, la persona que escribió el documento ha tomado prestado, en la práctica, tu acceso.

PCMag compara la seguridad de los prompts con tapar agujeros en una piedra porosa. Sellas una abertura y el agua encuentra otra. «Un ataque se abre paso; se corrige, pero quedan incontables vías de ataque por descubrir simplemente por lo dinámicos que son sistemas como los LLM».

Ejemplo: En junio de 2025, investigadores de Aim Security descubrieron EchoLeak, una vulnerabilidad que engañaba a Microsoft 365 Copilot para que filtrara información privada de la empresa. Cuando un empleado hacía una pregunta rutinaria de trabajo, Copilot podía recuperar el correo, seguir las instrucciones ocultas en él y enviar información sensible al atacante. El ataque eludió los controles diseñados para detectar instrucciones maliciosas y eliminar enlaces sospechosos.

Qué puedes hacer:

• Sigue la «regla de dos» de Meta: EchoLeak necesitaba una IA que pudiera leer datos de la empresa, leer correos externos y enviar información al exterior, y tenía las tres capacidades. Limitarla a dos de ellas impide que una inyección de prompts obtenga demasiado control. Si la tarea necesita las tres, exige la aprobación de una persona antes de cada acción.
• Haz pruebas con atacantes que conozcan tus defensas: Proporciona a tus evaluadores de seguridad las reglas y los filtros que has implantado y deja que intenten sortearlos. En un estudio, los atacantes que se adaptaron a las defensas tuvieron éxito más del 90 % de las veces frente a la mayoría de las 12 defensas evaluadas.

2. Evita que se filtre información sensible

Cuando un sistema de IA proporciona información privada a personas que no deberían verla, se habla de divulgación de información sensible. Esto podría suponer revelar los datos de pago de un cliente o dejar conversaciones privadas en una base de datos compartida.

Muchas filtraciones empiezan por «compartir de más». Imagina que una empresa conecta su IA a unidades de almacenamiento y bases de conocimiento con permisos poco restrictivos. La IA recupera todo lo que tiene a su alcance, exactamente como se diseñó. Nadie tiene que colarse, pero, a efectos prácticos, el LLM ya está comprometido.

Ejemplo: En enero de 2025, investigadores de Wiz encontraron una base de datos de DeepSeek expuesta a internet con más de un millón de entradas de registro, entre ellas historiales de chat y claves de API, que el software usa para acceder a otros servicios. Los investigadores no necesitaron convencer al modelo de que revelara nada.

Qué puedes hacer:

• Comprueba el acceso antes de que la IA lea los datos: Tu aplicación debe comprobar qué documentos puede ver la persona que hace la pregunta antes de pasárselos al modelo.
• Protege los registros que deja tu IA: Elimina los datos privados y las claves secretas antes de guardar los registros de actividad, exige inicio de sesión y restringe el acceso a las personas que los necesiten. Establece un periodo de conservación para que esos registros no se acumulen indefinidamente.

3. Controla la agencia excesiva

Las IA con agencia excesiva tienen más poder del que requiere su trabajo: herramientas que no necesitan, permisos que van más allá de su tarea o libertad para actuar sin verificar. Aquí la causa es irrelevante.

Un prompt de inyección, un error de software o un modelo que simplemente se equivoca llevan al mismo resultado. Tarde o temprano, la IA hará algo destructivo si tiene la capacidad de hacerlo.

Ejemplo: En julio de 2025, Jason Lemkin, fundador de SaaStr, contó que el agente de programación de Replit había eliminado su base de datos de 1206 registros de directivos, a pesar de las instrucciones de no hacer cambios. Al principio, el agente dijo que los datos no se podían restaurar, aunque más tarde se comprobó que era posible recuperarlos. Jason descubrió que decirle que no tocara la base de datos no le había quitado la capacidad de eliminarla.

Ampliar

Fuente: X

Qué puedes hacer:

• Elimina las capacidades que la tarea no necesita: Limita tanto las herramientas que recibe un agente como lo que pueden hacer esas herramientas. Un asistente que resume correos necesita permiso para leerlos, no para enviarlos ni eliminarlos.
• Coloca las comprobaciones de permisos fuera de la IA: Cada vez que se solicite una acción, haz que se compruebe con tus reglas de seguridad y exige que una persona la apruebe.

4. Revisa lo que entra en tu cadena de suministro de IA

Pocas empresas crean IA desde cero, y cada año son menos. Según la encuesta The State of Generative AI in the Enterprise de 2025 de Menlo Ventures, el 53 % de las empresas compró modelos de IA en 2024, una cifra que aumentó al 76 % en 2025.

La mayoría de las veces, las empresas descargan modelos de plataformas como Hugging Face, los siguen entrenando con conjuntos de datos que han recopilado otras personas e incorporan complementos y paquetes de código escritos por desconocidos.

Cada una de esas piezas es una vía de entrada. Si se manipula una de ellas, el problema llega integrado en tu producto.

Ejemplo: Los repositorios públicos de modelos de Hugging Face pasaron de 2,43 a 2,96 millones entre enero y agosto de 2026. Sin embargo, en julio de 2026, los modelos de OpenAI eludieron los controles destinados a mantenerlos sin acceso a internet durante unas pruebas de seguridad internas y se infiltraron en partes de los sistemas de Hugging Face. De hecho, un agente obtuvo 14 credenciales de acceso expuestas públicamente, comprobó que funcionaban y las compartió con otros agentes. Los agentes llegaron a aprovechar vulnerabilidades que les permitieron ejecutar código en los servidores de Hugging Face.

«Estamos imponiendo requisitos de alineación más estrictos a lo largo de todo el ciclo de vida de los modelos y creando entornos aislados más herméticos, restringiendo el acceso a internet y controlando aún más el acceso a los pesos de los modelos», según el informe de OpenAI.

Qué puedes hacer:

• Fija los modelos a una versión exacta y verifícalos: Fija cada modelo a una versión revisada y comprueba la huella digital de su archivo antes de cargarlo, para que no se pueda colar un archivo sustituido con la misma etiqueta. OWASP también recomienda las firmas digitales, con una salvedad: una firma demuestra de dónde procede un modelo, no que sea seguro.
• Comprueba cada paquete que sugiera tu IA: Antes de instalar un paquete de código que te haya recomendado un asistente de IA, confirma que existe, que es el paquete que buscabas y que procede del editor que esperas.

5. Protégete del envenenamiento de datos y modelos

Una IA envenenada aprende de datos corruptos. Pueden ser los ejemplos con los que se hizo su ajuste fino o una base de conocimiento en la que busca respuestas. El modelo parece seguir funcionando; simplemente aprende lecciones equivocadas y, a veces, aprende a comportarse mal solo cuando ve una frase desencadenante concreta.

Esa frase pasará desapercibida en todas las pruebas que hagas hasta que alguien la use.

Ampliar

Además, es muy difícil de revertir. El envenenamiento no es un error que se pueda corregir con un parche. Si tus datos son incorrectos, puede que tengas que volver a revisarlos, reentrenar el modelo o sustituirlo por completo.

Ejemplo: En octubre de 2025, investigadores de Anthropic, el UK AI Security Institute y el Alan Turing Institute demostraron que 250 documentos envenenados bastaban para enseñar a un modelo a generar galimatías cada vez que encontraba un desencadenante concreto. La misma cifra funcionó en los cuatro tamaños de modelo evaluados, aunque el más grande se entrenó con más de 20 veces la cantidad de datos limpios.

Qué puedes hacer:

• Controla de dónde proceden tus datos: Lleva un registro de cada conjunto de datos y modelo que uses, de dónde procede cada uno y qué cambió entre versiones. Recomendamos usar control de versiones para los conjuntos de datos, de modo que, si se detecta un envenenamiento, puedas volver a una versión limpia y averiguar cómo se introdujo.
• Busca puertas traseras: Una «puerta trasera» es un comportamiento oculto que un atacante introduce en un modelo y que espera a que una frase concreta u otro desencadenante lo active. Haz pruebas con entradas diseñadas para que el modelo incumpla sus reglas habituales.

6. Pon límites al consumo ilimitado

Cuando las IA no tienen ningún límite en cuanto al trabajo que pueden hacer o a lo que pueden costar, se considera que su consumo es «ilimitado». La mayoría de los servicios de IA cobran por uso, así que un atacante podría disparar tu factura o crear una copia de tu modelo.

OWASP denomina al problema de fondo «asimetría de costes». Una solicitud breve y barata puede desencadenar un procesamiento costoso por tu parte.

Ejemplo: En mayo de 2024, el Threat Research Team de Sysdig descubrió un nuevo ataque llamado «LLMjacking». Un grupo de atacantes se dirigió contra 10 servicios de LLM alojados en la nube utilizando credenciales robadas. Entraron a través de una versión vulnerable de Laravel y, después, averiguaron qué permitían hacer las credenciales y qué cuotas tenían, con el evidente objetivo de vender el acceso. También consultaron muchos ajustes de registro, probablemente para no ser detectados. Según Sysdig, en el peor de los casos, el ataque podría costarle a la víctima más de 46 000 dólares al día.

Qué puedes hacer:

• Establece presupuestos que frenen el gasto: Define límites de gasto estrictos para usuarios individuales, claves de API, equipos y la cuenta en su conjunto. Aplícalos en todos los puntos por los que puedan entrar solicitudes.
• Dale a cada tarea un punto de parada: Limita cuánto tiempo puede ejecutarse una tarea, cuánto texto puede procesar y generar, y cuántas llamadas a herramientas puede hacer. Añade cortes automáticos para los agentes que se repitan o superen su asignación.

7. Detecta la desinformación antes de actuar

Cuando una IA genera algo falso que parece correcto, y alguien, o algo, actúa en consecuencia, se habla de desinformación. El riesgo principal no es tanto la respuesta errónea en sí como que esa respuesta errónea se dé por buena y se utilice.

El historial de incidentes sugiere que a los profesionales no les preocupaba la desinformación tanto como debería haberles preocupado. Según la carta de presentación de la edición de 2026, los votantes la situaron cerca del final de la lista, pero, a juzgar por los incidentes reales, está cerca de los primeros puestos.

Ejemplo: En 2025, Deloitte Australia entregó una revisión de los sistemas informáticos de prestaciones sociales en el marco de un contrato público de 440 000 dólares australianos. Chris Rudge, investigador de la Universidad de Sídney, encontró referencias a investigaciones inexistentes y una cita inventada de una sentencia de un tribunal federal. El informe revisado reveló que Deloitte había utilizado Azure OpenAI GPT-4o en su metodología, y la firma accedió a devolver el último pago. Y, por desgracia, se trataba de una revisión de aseguramiento.

Qué puedes hacer:

• Comprueba que las evidencias respaldan la respuesta: Fundamenta las afirmaciones en fuentes actuales y fiables. Para una respuesta sobre políticas, recupera la política aprobada y comprueba que respalda la conclusión, incluidas sus excepciones.
• Verifica antes de que el sistema actúe: Si un agente dice que un cliente ha superado una verificación de identidad, confírmalo con el sistema de verificación antes de liberar un pago. Exige la aprobación de una persona para las decisiones importantes y pon las evidencias a disposición de quien las revise.

8. Limita los daños de la exposición del contexto oculto

Las aplicaciones de IA proporcionan al modelo instrucciones e información de contexto que los usuarios no suelen ver. Esto puede incluir el prompt del sistema, las políticas internas, las descripciones de las herramientas disponibles y las reglas sobre quién puede usarlas. Se produce una exposición del contexto oculto cuando el modelo revela esa información a alguien.

En 2026, OWASP amplió esta entrada, antes llamada «filtración del prompt del sistema», porque el prompt del sistema es solo una parte de lo que puede escaparse. El peligro depende de lo que hayas puesto ahí. Que se filtre una guía de tono de voz resulta algo embarazoso, pero que se filtre una clave de API da a alguien acceso a tu base de datos confidencial.

Ejemplo: En febrero de 2023, unos usuarios consiguieron que Bing Chat de Microsoft revelara sus instrucciones internas. Uno de los intentos con éxito fue el de Marvin von Hagen, que afirmó ser desarrollador de OpenAI y pidió las instrucciones para poder configurar el modelo. Bing reveló las reglas que regían sus búsquedas, sus respuestas y su comportamiento de seguridad, junto con su nombre interno, Sydney. Entre las instrucciones reveladas había una que le indicaba mantener esas instrucciones en secreto.

Qué puedes hacer:

• Mantén los secretos fuera del contexto del modelo: Da por hecho que cualquier cosa que el modelo pueda leer podría acabar siendo visible para los usuarios; guarda las contraseñas, las claves de API y los tokens de acceso en un sistema independiente de gestión de secretos.
• Haz que los permisos se mantengan aunque se filtren las reglas: Aplica las comprobaciones de acceso en el código de tu aplicación. Si una herramienta está restringida a los administradores, comprueba los permisos de la cuenta del usuario antes de ejecutarla.

9. Blinda tus vectores y embeddings

Cuando una IA utiliza la búsqueda vectorial para encontrar respuestas en los documentos de tu empresa, no busca directamente en el texto. Los documentos se convierten en «embeddings», que son largas listas de números que capturan el significado de cada fragmento, y se almacenan en una base de datos vectorial. Las preguntas se convierten de la misma forma, y el sistema recupera los fragmentos cuyos números están más próximos.

OWASP resume las cuatro formas en que puede fallar: el envenenamiento hace que el sistema se equivoque, la inversión provoca filtraciones, el bloqueo lo deja mudo y un control de acceso deficiente hace que entregue cualquier cosa a cualquiera.

Los números no son la abstracción segura que aparentan. Los embeddings almacenados pueden volver a convertirse en texto, y un método recuperó de forma exacta el 92 % de los fragmentos cortos de 32 tokens en sus pruebas. Por eso, una copia de seguridad filtrada «solo de embeddings» también puede exponer el contenido de los documentos.

Ejemplo: En una investigación presentada en USENIX Security 2025, unos investigadores demostraron que un único documento cuidadosamente elaborado podía impedir que una IA respondiera a una pregunta concreta. Lo añadieron a la colección en la que buscaba la IA. Cuando la IA lo encontraba, podía responder que no tenía suficiente información o que responder no sería seguro. El documento no necesitaba indicar a la IA que ignorara sus reglas. Esto se conoce como «bloqueo de la recuperación».

Qué puedes hacer:

• Mantén índices separados para los datos públicos y los privados: No mezcles contenido extraído de la web con datos de socios o documentos internos confidenciales. Separa físicamente los datos por nivel de confianza en lugar de etiquetar el contenido dentro de un mismo índice: así eliminas toda una categoría de errores de configuración y el contenido extraído de internet no puede acabar junto a los documentos de tu consejo de administración.
• Trata los embeddings como los documentos de los que proceden: Cífralos, protege las copias de seguridad de la base de datos vectorial igual que los archivos de origen y elimina los embeddings cuando elimines el original. Las claves de API de tu servicio de embeddings deben mantenerse en secreto.

10. Revisa la salida de la IA antes de transmitirla

Siempre que una aplicación transmite la salida de la IA a otro sistema sin verificar si es segura para usarla allí, está gestionando de forma inadecuada la salida del LLM.

Esta entrada también abarca el código inseguro que los asistentes de programación con IA generan a gran escala. Por tanto, cada línea que escribe un asistente también es salida.

Ejemplo: En 2025, el investigador Johann Rehberger demostró cómo el asistente de programación Amp de Sourcegraph podía filtrar contenido del chat simplemente mostrando una imagen. Utilizó una inyección de prompts para hacer que Amp incluyera información privada en la dirección web de una imagen. A continuación, la aplicación cargó automáticamente esa imagen, con lo que envió la información a su servidor. El fallo en la gestión de la salida fue esa solicitud automática: el texto que generó el modelo se convirtió en una conexión con un servidor externo que llevaba consigo datos privados.

Qué puedes hacer:

• Haz que la salida sea segura para su destino: Comprueba y trata las respuestas según adónde vayan a ir. En una página web, impide que el texto generado se convierta en código ejecutable. En una base de datos, utiliza consultas preparadas que mantengan los valores proporcionados separados de los comandos.
• Impide que las respuestas establezcan conexiones externas automáticas: Desactiva de forma predeterminada la carga automática de imágenes, vistas previas de enlaces y páginas incrustadas en las respuestas del modelo. Limita las conexiones necesarias a destinos aprobados explícitamente.

¿Cómo protege Perplexity los LLM?

Partimos de la base de que todos los riesgos anteriores acabarán materializándose, y diseñamos nuestros sistemas para que, cuando eso ocurra, no puedan causar mucho daño. Nuestro CISO, Kyle Polley, explicó cómo lo hacemos en un taller reciente.

• El agente tiene su propio ordenador, y empieza vacío: Las herramientas de agentes instaladas en tu portátil pueden obtener acceso a los archivos, las aplicaciones y las credenciales guardadas del equipo. Perplexity Computer funciona al revés. Cada tarea se ejecuta en su propio entorno aislado y, como dice Polley, «de forma predeterminada no tiene acceso a nada».
• El agente nunca ve las contraseñas: Las credenciales de los servicios conectados se almacenan fuera del entorno aislado. Cuando el agente necesita acceder a un servicio como GitHub, envía una solicitud sin credenciales adjuntas. Una pasarela comprueba que el destino y la solicitud son los esperados y añade las credenciales justo cuando la solicitud sale. El agente puede usar la conexión sin llegar a obtener las claves.
• Tus permisos se mantienen, y puedes restringirlos aún más: Las conexiones establecidas mediante OAuth conservan tus permisos de acceso en el servicio conectado. Si tú no puedes ver algo, tu agente tampoco.
• Cada página web se trata como una desconocida: Creamos BrowseSafe para Comet, nuestro navegador agéntico, porque las herramientas que probamos no satisfacían nuestras necesidades en el uso real. El navegador analiza las páginas web y otro contenido externo, incluidos los correos electrónicos, en busca de inyecciones de prompts. Hemos publicado como código abierto tanto el modelo como el conjunto de datos.
• Vigilamos al agente y las máquinas en las que se ejecuta: Numbat se sitúa entre el momento en que un agente decide actuar y la ejecución real de la herramienta. Numbat registra la actividad de los agentes de programación compatibles y puede bloquear las acciones que infrinjan las políticas configuradas antes de que se ejecuten. Bumblebee hace un inventario de los paquetes de software de portátiles, servidores y pipelines de compilación, y señala los que se sabe que son maliciosos. Ambos son de código abierto.
• Los proveedores de modelos no conservan tus datos: Tenemos acuerdos de retención cero de datos con nuestros proveedores externos de LLM. Los administradores de Enterprise también pueden reducir el periodo de retención de datos de la propia Perplexity a tan solo 24 horas.

Creamos Numbat de forma proactiva, por un motivo que Polley resume en una frase: «Cuanta más autonomía le das a un agente, más riesgo hay».

Preguntas frecuentes sobre la seguridad de los LLM

¿Cuál es el LLM más seguro?

Ningún LLM hace que una aplicación sea segura por sí solo: los modelos pueden seguir confundiendo contenido que deberían leer con instrucciones que deberían seguir. Además, las defensas que parecen sólidas en las pruebas estándar pueden ceder bajo presión.

Una pregunta mejor es qué configuración es la más segura para tu caso de uso. Eso implica permisos limitados, credenciales alejadas del modelo, aprobación humana para las acciones de riesgo y pruebas realizadas por personas que conozcan tus defensas.

¿Qué son las vulnerabilidades de los LLM?

Las vulnerabilidades de los LLM son debilidades que hacen que un sistema de IA pueda ser engañado, filtrar datos o causar daños, ya sea a manos de un atacante o por sus propios errores.

Los diez riesgos principales son la inyección de prompts, la divulgación de información confidencial, la agencia excesiva, la cadena de suministro, el envenenamiento de datos y modelos, el consumo ilimitado, la desinformación, la exposición del contexto oculto, las debilidades de vectores y embeddings, y la gestión inadecuada de la salida.

¿Es seguro un LLM privado?

Es una opción más segura para algunas cosas, pero no por defecto. Si ejecutas un modelo en tu propia infraestructura o en un entorno en la nube, tienes más control sobre el tratamiento de los datos. Pero no hay ninguna forma automática de evitar las inyecciones de prompts, la agencia excesiva, el envenenamiento o la desinformación.

Al alojar el modelo por tu cuenta, también eres responsable del modelo que descargas, incluidos los riesgos de la cadena de suministro y la infraestructura que necesita.