¿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.º 1 del OWASP Top 10 para aplicaciones de LLM en todas las ediciones desde 2023.

La lista es lo más cercano a un consenso que existe en la seguridad de la IA. El proyecto comenzó como un pequeño grupo de profesionales de seguridad y ahora 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 convence a la IA de hacer cosas, así que no vamos a fingir que esto ya está resuelto. Wilson, codirector del 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 líder del proyecto nos pide "dejar de intentar construir un modelo que no pueda ser engañado" y diseñar el sistema que lo rodea de modo que un modelo engañado no pueda dañar nada importante.

Mantendremos esa postura a lo largo de 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 usan contra ataques y usos indebidos. El riesgo crece según 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 el software bien protegido hay una separación clara entre las instrucciones que sigue un programa y la información que procesa. Pero los LLM no tienen esa separación.

Todo lo que lee el modelo llega como un único y largo flujo de texto: las instrucciones del desarrollador, tu pregunta, una página web que consultó. En teoría, los modelos de IA deben distinguir quién está hablando, ya sea el desarrollador, el usuario o el propio modelo mientras razona 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 esquema de seguridad que dependa de que el modelo sepa quién está al mando.

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

La seguridad de los LLM implica aceptar que el modelo a veces recibirá órdenes de la persona equivocada y rodearlo de barreras de protección de IA que resistan incluso cuando eso ocurra.

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

Recorreremos 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 sencilla de cómo pueden salir mal las cosas y un ejemplo real. Después, veremos las prácticas que pueden ayudar a prevenirlo o, al menos, a limitar el daño.

1. Contén la inyección de prompts

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

El segundo tipo se conoce como inyección indirecta de prompts. Le pides a tu asistente que resuma un documento. Quien lo escribió le indicó al asistente que le enviara tus archivos privados. Si el asistente sigue esas instrucciones, la persona que escribió el documento prácticamente tomó prestado 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 logra abrirse paso; se corrige, pero quedan innumerables 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 falla que engañaba a Microsoft 365 Copilot para que filtrara información privada de la empresa. Cuando un empleado hacía una pregunta laboral rutinaria, Copilot podía extraer el correo, seguir las instrucciones ocultas en él y enviar información sensible al atacante. El ataque evadió los controles diseñados para detectar instrucciones maliciosas y eliminar enlaces sospechosos.

Qué puedes hacer:

• Sigue la “Regla de dos” de Meta: EchoLeak requería una IA capaz de leer datos de la empresa, leer correos externos y enviar información hacia afuera, y contaba con las tres capacidades. Limitarla a dos de ellas evita que una inyección de prompts obtenga demasiado control. Si la tarea requiere las tres, exige la aprobación de una persona antes de cada acción.
• Haz pruebas con atacantes que conozcan tus defensas: Entrega a tus evaluadores de seguridad las reglas y los filtros que implementaste, y deja que intenten burlarlos. En un estudio, los atacantes que se adaptaron a las defensas tuvieron éxito más del 90% de las veces contra la mayoría de las 12 defensas evaluadas.

2. Evita que se filtre información sensible

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

Muchas filtraciones comienzan con “compartir de más”. Supongamos que una empresa conecta su IA a unidades de almacenamiento y bases de conocimiento con permisos poco estrictos. La IA recupera todo lo que tiene a su alcance, exactamente como fue diseñada. Nadie tiene que irrumpir en el sistema, pero considera que el LLM ya fue vulnerado.

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 registros, incluidos historiales de chat y claves de API, que el software usa para acceder a otros servicios. Los investigadores no tuvieron que persuadir al modelo para que revelara nada.

Qué puedes hacer:

• Verifica 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 lo necesiten. Establece un período de retenció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 su trabajo requiere: 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 para hacerlo.

Ejemplo: En julio de 2025, el fundador de SaaStr, Jason Lemkin, informó que el agente de programación de Replit eliminó su base de datos con 1,206 registros de ejecutivos, a pesar de las instrucciones de no hacer cambios. Al principio, el agente dijo que los datos no se podían restaurar, aunque después se comprobó que sí 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 electrónicos necesita permiso para leerlos, no para enviarlos ni eliminarlos.
• Coloca las verificaciones de permisos fuera de la IA: Cada vez que se solicite una acción, haz que se verifique 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 2025 de Menlo Ventures, el 53% compró modelos de IA en 2024, 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 recopilaron otras personas e integran complementos y paquetes de código escritos por desconocidos.

Cada una de esas piezas es una puerta de entrada. Si alguna se manipula, el problema termina dentro de tu producto.

Ejemplo: Los repositorios públicos de modelos de Hugging Face pasaron de 2.43 millones a 2.96 millones entre enero y agosto de 2026. Sin embargo, en julio de 2026, los modelos de OpenAI eludieron los controles diseñados para mantenerlos desconectados de internet durante pruebas internas de seguridad e irrumpieron en partes de los sistemas de Hugging Face. De hecho, un agente recuperó 14 credenciales de acceso expuestas públicamente, comprobó que funcionaban y las compartió con otros agentes. Luego, los agentes aprovecharon fallas que les permitieron ejecutar código en los servidores de Hugging Face.

“Estamos imponiendo requisitos más estrictos de alineación a lo largo del ciclo de vida de un modelo y creando entornos aislados más restrictivos, limitando el acceso a internet y controlando aún más el acceso a los pesos de los modelos”, indica 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 cuele un archivo sustituido bajo la misma etiqueta. OWASP también recomienda las firmas digitales, con una salvedad: una firma demuestra de dónde proviene un modelo, no que sea seguro.
• Revisa cada paquete que te sugiera tu IA: Antes de instalar un paquete de código que te haya recomendado un asistente de IA, confirma que exista, que sea el paquete que buscabas y que provenga del editor que esperas.

5. Protégete contra el 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 las lecciones equivocadas y, a veces, aprende a comportarse mal solo cuando ve una frase desencadenante específica.

La 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 puedas corregir con un parche. Si tus datos son incorrectos, quizá tengas que volver a revisarlos, reentrenar el modelo o reemplazarlo por completo.

Ejemplo: En octubre de 2025, investigadores de Anthropic, del UK AI Security Institute y del Alan Turing Institute demostraron que 250 documentos envenenados podían enseñarle a un modelo a producir texto sin sentido cada vez que encontraba un desencadenante específico. La misma cantidad funcionó en los cuatro tamaños de modelo evaluados, aunque el más grande se entrenó con más de 20 veces más datos limpios.

Qué puedes hacer:

• Rastrea el origen de tus datos: Lleva un registro de cada conjunto de datos y modelo que usas, de dónde proviene cada uno y qué cambió entre versiones. Recomendamos usar control de versiones para los conjuntos de datos; así, si aparece un envenenamiento, puedes 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 implanta en un modelo y que espera una frase concreta u otro desencadenante para activarse. Haz pruebas para detectarlas con entradas diseñadas para que el modelo rompa sus reglas habituales.

6. Pon límites al consumo ilimitado

Cuando las IA no tienen límites sobre cuánto trabajo pueden hacer o cuánto 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 llama al problema central “asimetría de costos”. Una solicitud breve y barata puede desencadenar un cómputo costoso de tu lado.

Ejemplo: En mayo de 2024, el Threat Research Team de Sysdig descubrió un nuevo ataque llamado “LLMjacking”. Un grupo de atacantes tuvo como blanco 10 servicios de LLM alojados en la nube usando credenciales robadas. Entraron a través de una versión vulnerable de Laravel y luego averiguaron qué podían hacer las credenciales y cuáles eran sus cuotas, con el evidente objetivo de vender el acceso. También consultaron muchas configuraciones de registro, probablemente para evitar ser detectados. Según Sysdig, en el peor de los casos, esto podría costarle a la víctima más de 46,000 dólares al día.

Qué puedes hacer:

• Establece presupuestos que detengan el gasto: Fija 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. Agrega cortes automáticos para los agentes que se repitan o que excedan su límite.

7. Detecta la desinformación antes de actuar

Cuando una IA produce algo falso que parece correcto y alguien, o algo, actúa en consecuencia, se le llama desinformación. El riesgo central no es tanto la respuesta incorrecta en sí, sino que se confíe en esa respuesta incorrecta y se use.

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

Ejemplo: En 2025, Deloitte Australia entregó una revisión de los sistemas de TI de asistencia social en el marco de un contrato gubernamental 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 usado Azure OpenAI GPT-4o en su metodología, y la firma aceptó reembolsar el último pago. Lamentablemente, se trataba de una revisión de aseguramiento.

Qué puedes hacer:

• Comprueba que la evidencia respalde la respuesta: Fundamenta las afirmaciones en fuentes actuales y autorizadas. Para una respuesta sobre políticas, recupera la política aprobada y comprueba que respalde la conclusión, incluidas sus excepciones.
• Verifica antes de que el sistema actúe: Si un agente dice que un cliente superó 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 la evidencia de respaldo a disposición de quien las revise.

8. Limita el daño de la exposición del contexto oculto

Las aplicaciones de IA le dan al modelo instrucciones e información de contexto que los usuarios normalmente no ven. Eso puede incluir el prompt del sistema, políticas internas, descripciones de las herramientas disponibles y reglas sobre quién puede usarlas. Una exposición del contexto oculto ocurre cuando el modelo le 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 filtrarse. El peligro depende de lo que hayas puesto ahí. Que se filtre una guía de tono de voz resulta un poco vergonzoso, pero una clave de API filtrada le 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 exitosos fue el de Marvin von Hagen, quien afirmó ser desarrollador de OpenAI y pidió las instrucciones para poder configurar el modelo. Bing reveló las reglas que regían sus búsquedas, respuestas y comportamiento de seguridad, junto con su nombre interno, Sydney. Entre las instrucciones reveladas había una que le indicaba mantener esas instrucciones como confidenciales.

Qué puedes hacer:

• Mantén los secretos fuera del contexto del modelo: Asume que cualquier cosa que el modelo pueda leer podría quedar a la vista de 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, verifica los permisos de la cuenta del usuario antes de ejecutarla.

9. Protege tus vectores y embeddings

Cuando una IA usa 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 manera, y el sistema recupera los fragmentos cuyos números quedan más cerca.

OWASP resume las cuatro formas en que falla: el envenenamiento hace que el sistema se equivoque, la inversión hace que filtre información, la interferencia hace que se quede en silencio y un control de acceso deficiente hace que le entregue cualquier cosa a cualquiera.

Los números no son la abstracción segura que parecen. Los embeddings almacenados se pueden volver a convertir en texto, y un método logró recuperar con exactitud el 92% de los fragmentos cortos de 32 tokens en sus pruebas. Así que una copia de seguridad filtrada que contenga “solo embeddings” también puede exponer el contenido de los documentos.

Ejemplo: En una investigación presentada en USENIX Security 2025, los investigadores demostraron que un solo documento cuidadosamente elaborado podía impedir que una IA respondiera una pregunta concreta. Lo agregaron 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 no era seguro contestar. El documento ni siquiera tenía que indicarle a la IA que ignorara sus reglas. Esto se conoce como “interferencia en 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 ni con documentos internos confidenciales. Separa físicamente el contenido según su nivel de confianza en lugar de etiquetarlo 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 terminar junto a los documentos de tu consejo de administración.
• Trata los embeddings como los documentos de los que provienen: Cífralos, protege las copias de seguridad de la base de datos vectorial además de 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 pasa la salida de la IA a otro sistema sin verificar si es segura para usarse ahí, está manejando de forma inadecuada la salida del LLM.

Esta categoría también abarca el código inseguro que los asistentes de programación con IA generan a gran escala. Por lo 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 el contenido del chat con solo mostrar una imagen. Usó una inyección de prompts para que Amp incluyera información privada en la dirección web de una imagen. Después, la aplicación descargó automáticamente esa imagen y, con ello, envió la información a su servidor. La falla en el manejo de la salida fue esa solicitud automática: el texto que generó el modelo se convirtió en una conexión a un servidor externo que llevaba consigo datos privados.

Qué puedes hacer:

• Haz que la salida sea segura para su destino: Revisa y procesa las respuestas según el lugar al que van a llegar. En una página web, evita que el texto generado se convierta en código ejecutable. En una base de datos, usa consultas preparadas que mantengan los valores proporcionados separados de los comandos.
• Evita 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 del supuesto de que todos los riesgos anteriores terminarán por materializarse, 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 propia computadora, y empieza vacía: Las herramientas de agentes instaladas en tu laptop pueden acceder a los archivos, las apps y las credenciales guardadas en ella. 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. Una puerta de enlace comprueba que el destino y la solicitud sean los esperados y, después, agrega las credenciales justo antes de que la solicitud salga. El agente puede usar la conexión sin llegar a tener las claves.
• Tus permisos se mantienen, y puedes restringirlos aún más: Las conexiones realizadas 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 fuente 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. Publicamos 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, antes de que se ejecuten, las acciones que infrinjan las políticas configuradas. Bumblebee hace un inventario de los paquetes de software en laptops, servidores y pipelines de compilación, y marca los que se sabe que son maliciosos. Ambos son de código abierto.
• Los proveedores de modelos no conservan tus datos: Tenemos acuerdos de cero retención de datos con nuestros proveedores externos de LLM. Además, los administradores de cuentas empresariales pueden configurar la retención de datos de Perplexity para que dure tan solo 24 horas.

Creamos Numbat de forma proactiva, por una razón que Polley resume en una sola 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 aún pueden confundir el 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 mejor pregunta es qué configuración es la más segura para tu caso de uso. Eso implica permisos limitados, credenciales fuera del alcance del modelo, aprobación humana para las acciones riesgosas y pruebas realizadas por personas que conozcan tus defensas.

¿Qué son las vulnerabilidades de los LLM?

Las vulnerabilidades de los LLM son debilidades que permiten que un sistema de IA sea engañado, filtre datos o cause daños, ya sea por obra 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 el manejo inadecuado de la salida.

¿Es seguro un LLM privado?

Es una opción más segura para algunas cosas, pero no de forma predeterminada. Tienes más control sobre el manejo de los datos si ejecutas un modelo en tu propia infraestructura o en un entorno de nube. No hay una forma automática de prevenir las inyecciones de prompts, la agencia excesiva, el envenenamiento ni 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 requiere.