OWASP Top 10 para aplicaciones LLM: guía de los principales riesgos

El OWASP Top 10 para aplicaciones LLM es la lista de referencia de los diez riesgos de seguridad más críticos en aplicaciones basadas en modelos de lenguaje. En su edición 2026, publicada en agosto, encabezan la lista la inyección de prompts, la divulgación de información sensible y la autonomía excesiva de los agentes.

Cada vez más empresas integran LLMs en chatbots, asistentes internos, sistemas RAG, copilotos y agentes con acceso a herramientas. Muchas de ellas siguen aplicando a estas aplicaciones los mismos controles que a una aplicación web tradicional. El problema es que un LLM introduce riesgos que esos controles no cubren: puede ser manipulado mediante el contenido que procesa, revelar información a la que no debería acceder o ejecutar acciones que nadie autorizó.

¿Qué es el OWASP Top 10 para aplicaciones LLM?

El OWASP Top 10 para aplicaciones LLM es una lista de concienciación elaborada por la comunidad. Identifica los diez riesgos de seguridad más críticos en aplicaciones que utilizan grandes modelos de lenguaje, y la mantiene el OWASP GenAI Security Project, parte de la fundación OWASP.

Su objetivo no es certificar aplicaciones, sino ofrecer a desarrolladores, equipos de seguridad y responsables de riesgo un lenguaje común para identificar, priorizar y mitigar las amenazas propias de la IA generativa.

OWASP Top 10 LLM vs. Agentic Top 10 vs. MCP Top 10

OWASP mantiene hoy tres listas complementarias. Cada una cubre una capa distinta de una aplicación de IA:

• OWASP Top 10 para aplicaciones LLM: cubre el modelo y la aplicación que lo envuelve: entradas, salidas, datos, RAG y permisos. Es la lista más madura y la base de las otras dos.
• OWASP Top 10 para aplicaciones agénticas (Agentic Top 10): se publicó en diciembre de 2025 y se centra en los riesgos que aparecen cuando la IA deja de responder y empieza a actuar. Incluye el secuestro de objetivos del agente, el uso indebido de herramientas, el abuso de privilegios y los agentes descontrolados.
• OWASP MCP Top 10: cubre el Model Context Protocol, el estándar que conecta asistentes y agentes con herramientas y datos externos. Aborda riesgos como el envenenamiento de herramientas, la escalada de privilegios por ampliación de permisos o los servidores MCP no autorizados ("shadow MCP servers"). Sigue en fase beta.

Una empresa que despliega agentes conectados a sistemas internos mediante MCP necesita tener en cuenta las tres.

Qué cambia en la edición 2026 del OWASP Top 10 para LLM

La edición 2026 conserva las diez categorías de 2025, pero reordena ocho de ellas y renombra una. Además, introduce un cambio metodológico relevante: el ranking combina la votación de profesionales con datos de incidentes reales, en lugar de basarse solo en la percepción de la comunidad.

El mensaje de conjunto es claro: los riesgos que más suben son los que tienen consecuencias operativas, porque las aplicaciones LLM ya no solo generan texto, sino que ejecutan acciones en sistemas empresariales.

Tres cambios merecen especial atención:

• La autonomía excesiva sube al tercer puesto. Es el mayor ascenso de la lista y refleja que los incidentes reales se concentran en despliegues con agentes conectados a herramientas.
• La fuga del system prompt se convierte en exposición de contexto oculto. El riesgo ya no se limita al texto del prompt de sistema. Ahora abarca todo el contexto que el usuario no ve.
• El consumo sin límites sube del décimo al sexto puesto. Los agentes que encadenan llamadas pueden disparar costes y agotar recursos con mucha más facilidad que un chatbot.

Los 10 riesgos de seguridad del OWASP Top 10 para LLM

LLM01 — Inyección de prompts (Prompt Injection)

Qué es: la manipulación del comportamiento del modelo mediante instrucciones maliciosas. Puede ser directa (el usuario escribe la instrucción) o indirecta (la instrucción está oculta en un documento, correo o página web que el modelo procesa).

Ejemplo de ataque: un proveedor envía un correo con instrucciones ocultas en texto blanco. Cuando un empleado pide a su asistente que resuma la bandeja de entrada, el modelo sigue esas instrucciones y reenvía información confidencial.

Impacto para la empresa: fuga de datos, acciones no autorizadas y pérdida de confianza en la herramienta.

Mitigaciones clave:

• Tratar todo contenido externo como no confiable.
• Separar instrucciones y datos.
• Aplicar filtros de detección de ataques.
• Limitar lo que el modelo puede hacer aunque sea manipulado.

LLM02 — Divulgación de información sensible

Qué es: la exposición de datos personales, información confidencial o propiedad intelectual a través de las respuestas del modelo.

Ejemplo de ataque: un asistente interno conectado a SharePoint responde a un empleado con fragmentos de un documento de nóminas, porque una carpeta antigua tenía permisos demasiado amplios.

Impacto para la empresa: incumplimiento del RGPD, pérdida de propiedad intelectual y daño reputacional.

Mitigaciones clave:

• Clasificar y etiquetar la información.
• Corregir el exceso de permisos antes de conectar la IA.
• Aplicar políticas DLP a las interacciones con IA.
• Excluir del entrenamiento y del contexto los datos sensibles innecesarios.

LLM03 — Autonomía excesiva (Excessive Agency)

Qué es: el riesgo de que una aplicación LLM tenga más funciones, permisos o autonomía de los que su tarea requiere. OWASP identifica tres causas: funcionalidad excesiva, permisos excesivos y autonomía excesiva.

Ejemplo de ataque: un agente de atención al cliente con permisos de escritura en el CRM es manipulado mediante inyección de prompts para modificar datos de facturación de varios clientes.

Impacto para la empresa: el error o la manipulación del modelo se convierte en una acción real, a veces irreversible, en sistemas de negocio.

Mitigaciones clave:

• Aplicar el principio de mínima autonomía.
• Dar a cada agente solo las herramientas imprescindibles.
• Separar permisos de lectura y escritura.
• Exigir aprobación humana en acciones irreversibles o de alto impacto.

LLM04 — Cadena de suministro

Qué es: las vulnerabilidades introducidas por modelos de terceros, conjuntos de datos, librerías, adaptadores o plugins que forman parte de la aplicación.

Ejemplo de ataque: un equipo descarga un modelo ajustado (fine-tuned) desde un repositorio público. El modelo incluye un comportamiento oculto que se activa ante ciertas palabras clave.

Impacto para la empresa: compromiso de la aplicación desde su origen, difícil de detectar con pruebas funcionales.

Mitigaciones clave:

• Usar catálogos de modelos aprobados.
• Verificar la procedencia y la integridad de modelos y datos.
• Mantener un inventario (AI-BOM) de componentes.
• Revisar las licencias y los términos de los proveedores.

LLM05 — Envenenamiento de datos y modelos

Qué es: la manipulación de los datos de entrenamiento, ajuste o recuperación para introducir sesgos, puertas traseras o comportamientos maliciosos.

Ejemplo de ataque: un atacante con acceso a una wiki interna modifica procedimientos que alimentan un sistema RAG. El asistente empieza a recomendar pasos incorrectos.

Impacto para la empresa: decisiones erróneas basadas en información manipulada y pérdida de integridad del sistema.

Mitigaciones clave:

• Controlar quién puede modificar las fuentes de datos.
• Validar los datos antes de indexarlos o usarlos en el entrenamiento.
• Monitorizar cambios anómalos en el comportamiento del modelo.

LLM06 — Consumo sin límites (Unbounded Consumption)

Qué es: el uso descontrolado de recursos (tokens, llamadas o cómputo) que provoca denegación de servicio, costes inesperados o extracción del modelo.

Ejemplo de ataque: un agente entra en un bucle de llamadas a herramientas y genera miles de peticiones al modelo en pocas horas, disparando la factura mensual.

Impacto para la empresa: costes imprevistos, degradación del servicio y riesgo de robo de propiedad intelectual del modelo.

Mitigaciones clave:

• Establecer límites de tokens y de frecuencia de peticiones.
• Fijar cuotas por usuario y por aplicación.
• Limitar el número de pasos de los agentes.
• Configurar alertas de consumo.

LLM07 — Desinformación

Qué es: la generación de información falsa o inexacta presentada con apariencia de fiabilidad, incluidas las "alucinaciones".

Ejemplo de ataque: un asistente jurídico interno cita una cláusula contractual que no existe. Un empleado la incluye en una respuesta a un cliente.

Impacto para la empresa: decisiones erróneas, riesgos legales y pérdida de credibilidad, sobre todo cuando las salidas alimentan procesos automatizados.

Mitigaciones clave:

• Anclar las respuestas en fuentes verificadas (RAG con citas).
• Detectar contenido sin fundamento.
• Mantener revisión humana en decisiones relevantes.
• Formar a los usuarios sobre las limitaciones del modelo.

LLM08 — Exposición de contexto oculto (Hidden Context Exposure)

Qué es: la revelación de información que el usuario no debería ver y que forma parte del contexto del modelo: el prompt de sistema, los esquemas de herramientas, las reglas de negocio, los documentos recuperados, la memoria y las respuestas de herramientas. Sustituye y amplía la antigua "fuga del system prompt".

Ejemplo de ataque: mediante preguntas encadenadas, un atacante obtiene el esquema completo de las herramientas de un agente y las reglas internas de aprobación. Con esa información prepara una inyección de prompts mucho más precisa.

Impacto para la empresa: OWASP lo considera un amplificador: no suele ser el daño final, pero facilita los ataques de los riesgos LLM01 y LLM03.

Mitigaciones clave:

• Asumir que todo el contexto puede llegar a ser legible.
• No incluir nunca credenciales ni secretos en el contexto.
• Aplicar la autorización fuera del modelo, en la capa de aplicación.

LLM09 — Debilidades en vectores y embeddings

Qué es: las vulnerabilidades en la forma en que se generan, almacenan y recuperan los embeddings en sistemas RAG, incluidas las bases de datos vectoriales.

Ejemplo de ataque: un índice vectorial compartido no respeta los permisos de los documentos de origen. Un usuario del departamento comercial recupera fragmentos de documentos del comité de dirección.

Impacto para la empresa: fuga de información entre usuarios o departamentos y manipulación de los resultados recuperados.

Mitigaciones clave:

• Aplicar control de acceso a nivel de documento en la recuperación ("security trimming").
• Separar índices por nivel de sensibilidad.
• Validar los datos antes de vectorizarlos.

LLM10 — Gestión inadecuada de las salidas

Qué es: el uso de las respuestas del modelo en otros sistemas sin validarlas ni sanearlas.

Ejemplo de ataque: una aplicación inserta la salida del modelo directamente en una consulta SQL. Un prompt manipulado genera una instrucción que borra registros.

Impacto para la empresa: vulnerabilidades clásicas (XSS, inyección SQL, ejecución remota de código) introducidas a través del LLM.

Mitigaciones clave:

• Tratar las salidas del modelo como entradas no confiables.
• Validar y codificar las salidas según el contexto.
• Usar consultas parametrizadas.
• Aplicar el mínimo privilegio en los sistemas que reciben las salidas.

Cómo aplicar el OWASP Top 10 para LLM en tu organización

El Top 10 solo aporta valor si se convierte en un proceso. Recomendamos cinco pasos:

1. Inventario de aplicaciones de IA. Identifica todos los asistentes, sistemas RAG, copilotos y agentes en uso, incluidos los integrados en herramientas de terceros. Para cada uno, documenta los datos a los que accede, las herramientas que puede usar y su responsable.
2. Modelado de amenazas. Analiza cada aplicación frente a los diez riesgos, empezando por los tres primeros. Una aplicación con agentes y acceso a escritura debe recibir más atención que un chatbot de solo lectura.
3. Pruebas y red teaming. Somete las aplicaciones a pruebas específicas de IA: inyección directa e indirecta, extracción de contexto, abuso de herramientas y consumo excesivo. Herramientas como PyRIT, de Microsoft, ayudan a automatizar parte de estas pruebas.
4. Controles por fase del ciclo de desarrollo. Integra los controles en diseño (mínima autonomía), desarrollo (validación de salidas), despliegue (filtros y límites) y operación (monitorización).
5. Revisión periódica. Repite la evaluación cuando cambien los modelos, las herramientas o los datos, y al menos una vez al año, coincidiendo con las actualizaciones de la lista de OWASP.

El OWASP Top 10 para LLM en entornos Microsoft

En el ecosistema Microsoft, la mayoría de los riesgos tienen un control técnico asociado. La responsabilidad, sin embargo, es compartida:

• Microsoft protege la plataforma y el modelo.
• La organización es responsable de los permisos, los datos, la configuración de los agentes y la monitorización.

En Microsoft 365 Copilot, los riesgos más relevantes para el cliente son la divulgación de información sensible por exceso de permisos, la inyección indirecta a través de documentos y correos, y la autonomía de los agentes creados en Copilot Studio. Para profundizar en cómo Copilot puede exponer datos a través de permisos mal configurados, consulta nuestro análisis sobre la exposición de datos a través de Microsoft Copilot.

Los agentes requieren además un gobierno de identidad específico: cada agente debe tener un responsable, permisos acotados y políticas de acceso. Lo explicamos en detalle en nuestra guía sobre la seguridad de las identidades de los agentes de IA.

OWASP Top 10 para LLM, Reglamento Europeo de IA y marcos de gobierno

El OWASP Top 10 es un marco técnico, no normativo. Su valor aumenta cuando se integra en un programa de gobierno de IA más amplio:

• NIST AI RMF: el Top 10 aporta los riesgos técnicos concretos que alimentan las funciones Map (identificar riesgos) y Measure (evaluarlos y probarlos) del marco. Para entender cómo estructurarlo, consulta nuestra guía del NIST AI Risk Management Framework.
• ISO/IEC 42001: las evaluaciones frente al Top 10 pueden servir como evidencia de los controles técnicos de un sistema de gestión de IA certificable.
• Reglamento Europeo de IA: exige que los sistemas de alto riesgo alcancen un nivel adecuado de solidez y ciberseguridad, incluida la resistencia frente a la manipulación de datos y modelos. Tras su modificación por el Digital Omnibus, las obligaciones para los sistemas de alto riesgo independientes del Anexo III se aplican desde el 2 de diciembre de 2027, según la información disponible a octubre de 2026.

Aplicar el OWASP Top 10 contribuye a demostrar la gestión de estos riesgos, pero no garantiza por sí solo el cumplimiento del Reglamento. El cumplimiento exige además gobierno, documentación, supervisión humana y gestión del ciclo de vida.

Checklist de seguridad para aplicaciones LLM

• Inventario de todas las aplicaciones de IA, con responsable, datos y herramientas documentados.
• Contenido externo tratado como no confiable y filtros de inyección de prompts activos.
• Datos sensibles clasificados y permisos corregidos antes de conectar la IA.
• Políticas DLP aplicadas a las interacciones con IA.
• Agentes con mínima autonomía, permisos de lectura y escritura separados y aprobación humana en acciones críticas.
• Modelos y componentes de terceros procedentes de fuentes aprobadas y verificadas.
• Fuentes de datos protegidas frente a modificaciones no autorizadas.
• Límites de tokens, de peticiones y de pasos de agentes configurados.
• Ningún secreto ni credencial incluido en el contexto del modelo.
• Recuperación RAG que respeta los permisos de los documentos de origen.
• Salidas del modelo validadas antes de llegar a otros sistemas.
• Registro y monitorización de interacciones, herramientas y alertas de seguridad de IA.
• Red teaming periódico y revisión tras cada cambio relevante.

El punto de partida técnico de la seguridad de IA generativa

La edición 2026 del OWASP Top 10 para LLM confirma una tendencia clara: el riesgo de la IA generativa se ha desplazado de lo que el modelo dice a lo que el modelo puede hacer y a lo que puede ver.

La autonomía excesiva, el consumo sin límites y la exposición de contexto oculto suben precisamente porque las empresas ya han conectado sus LLMs a sistemas reales.

Las organizaciones que adoptan el Top 10 como base de su programa de seguridad de IA ganan tres cosas:

• Un lenguaje común entre desarrollo, seguridad y negocio.
• Una forma estructurada de priorizar las inversiones en controles.
• Evidencia técnica que respalda su gobierno de IA y su preparación frente al Reglamento Europeo de IA.

ne Digital ayuda a las organizaciones a evaluar sus aplicaciones de IA frente al OWASP Top 10, implementar los controles en el ecosistema Microsoft (Foundry, Copilot, Purview, Entra y Defender) e integrar estas evaluaciones en un marco de gobierno de IA alineado con NIST AI RMF e ISO/IEC 42001.

¡Solicite una evaluación de seguridad de sus aplicaciones de IA!