OWASP Top 10 para LLM: diez riesgos que aparecen cuando la IA entra a producción
Conectar un LLM a datos y herramientas abre riesgos que el software tradicional no cubre por completo. OWASP los resume en diez.
Una aplicación con inteligencia artificial no falla solo cuando el modelo “se equivoca”. También puede obedecer una instrucción escondida en un documento, recuperar datos de la persona incorrecta o ejecutar una acción que nadie revisó.
El riesgo crece cuando el LLM deja de ser una ventana de chat y obtiene acceso a información, herramientas y procesos reales.
Para ordenar ese problema, el OWASP GenAI Security Project publicó el Top 10 for LLM and Generative AI Applications. Esta guía traduce sus diez categorías a decisiones concretas de arquitectura y operación.
Este artículo utiliza la edición OWASP Top 10 para LLM y GenAI 2025, revisada en julio de 2026. OWASP publicó además un Top 10 específico para aplicaciones agénticas 2026; es un recurso relacionado, no la misma lista.
| LA REGLA DE ORO |
|---|
| El LLM puede proponer una respuesta o una acción. Los datos, los permisos y el código deben decidir si está autorizado a verla o ejecutarla. |
El mapa completo
El Top 10 no asigna automáticamente la misma severidad a todas las empresas. Un chatbot que solo responde preguntas y un agente capaz de aprobar pagos no tienen el mismo impacto.
La lista funciona como un mapa: ayuda a encontrar dónde mirar antes de calcular probabilidad, impacto y riesgo residual en cada caso de uso.
| Frente de riesgo | Pregunta que lo descubre | Categorías OWASP |
|---|---|---|
| Manipulación | ¿Alguien puede alterar lo que la IA interpreta como instrucción o verdad? | LLM01, LLM04, LLM09 |
| Datos | ¿Puede recuperar, memorizar o revelar información que el usuario no debería conocer? | LLM02, LLM07, LLM08 |
| Acciones | ¿Una respuesta inesperada puede convertirse en código o en una operación real? | LLM05, LLM06 |
| Ecosistema y recursos | ¿Dependemos de componentes externos o de consumo sin límites? | LLM03, LLM10 |
| Riesgo | Qué puede ocurrir | Primer control útil |
|---|---|---|
| LLM01 — Prompt Injection | Una entrada cambia el comportamiento previsto | Separar contenido no confiable y limitar privilegios |
| LLM02 — Sensitive Information Disclosure | El sistema revela información que no corresponde | Minimizar datos y aplicar acceso por usuario |
| LLM03 — Supply Chain | Un modelo, dataset o componente externo está comprometido | Verificar procedencia, integridad y versiones |
| LLM04 — Data and Model Poisoning | Datos manipulados alteran el comportamiento del sistema | Validar, versionar y monitorear datos |
| LLM05 — Improper Output Handling | La salida se ejecuta como código, SQL o HTML confiable | Validar y codificar la salida según su destino |
| LLM06 — Excessive Agency | El agente posee demasiadas funciones, permisos o autonomía | Mínimo privilegio y aprobación humana |
| LLM07 — System Prompt Leakage | El prompt expone secretos o reglas internas | No guardar secretos ni autorización en el prompt |
| LLM08 — Vector and Embedding Weaknesses | RAG recupera datos incorrectos o no autorizados | Recuperación consciente de permisos |
| LLM09 — Misinformation | Una respuesta falsa parece suficientemente convincente | Fuentes verificables y revisión proporcional al impacto |
| LLM10 — Unbounded Consumption | El servicio pierde disponibilidad o presupuesto | Cuotas, límites, alertas y degradación controlada |
1. Prompt Injection: cuando el contenido intenta convertirse en una orden
El prompt injection aparece cuando una entrada altera la respuesta o el comportamiento del modelo de una manera no prevista.
Puede ser directo: el usuario escribe “ignora las reglas anteriores”. También puede ser indirecto: la instrucción está dentro de una página, un correo, una imagen o un PDF que el sistema procesa.
Imagina un asistente que compara propuestas comerciales. Un proveedor incorpora texto oculto en su archivo para que la IA recomiende su oferta. Si el documento se entrega al modelo sin una frontera clara entre datos e instrucciones, el asistente puede tratarlo como una orden.
RAG y fine-tuning pueden mejorar la relevancia, pero OWASP advierte que no eliminan por sí solos este riesgo.
Lo que sí reduce el impacto:
- Marcar páginas, archivos y resultados de búsqueda como contenido no confiable.
- Definir formatos de salida y validarlos con código.
- Limitar las herramientas disponibles y sus permisos.
- Exigir confirmación para acciones de alto impacto.
- Probar ataques directos, indirectos, codificados y multimodales.
2. Sensitive Information Disclosure: la IA revela más de lo permitido
Un LLM puede recibir datos personales, financieros, médicos, legales o comerciales. La exposición puede venir del entrenamiento, del historial de la conversación, de un documento recuperado por RAG o de una herramienta conectada.
Un caso típico ocurre cuando la autenticación funciona, pero la recuperación no conserva el alcance del usuario. El empleado entra correctamente con su cuenta y el asistente devuelve un fragmento perteneciente a otra área o cliente.
La protección empieza antes del prompt:
- Clasificar la información que podrá utilizar la solución.
- Enviar al modelo solo los datos necesarios.
- Enmascarar o tokenizar campos sensibles.
- Aplicar autorización por usuario, rol, organización y propósito.
- Definir retención, entrenamiento y eliminación.
- Detectar información sensible tanto en entradas como en salidas.
Decirle al modelo “no reveles datos” ayuda, pero no reemplaza controles de acceso verificables.
3. Supply Chain: la IA también depende de terceros
La cadena de suministro incluye más que bibliotecas de código. También contiene modelos base, datasets, repositorios, adaptadores LoRA, APIs, plataformas cloud y herramientas de orquestación.
Un archivo descargado desde un repositorio público puede estar manipulado. Un modelo puede quedar sin mantenimiento. Un proveedor puede cambiar sus condiciones y comenzar a utilizar los datos para entrenamiento. Incluso una licencia incompatible puede detener un proyecto después de llegar a producción.
Antes de incorporar un componente conviene registrar:
- Origen, versión y responsable de aprobación.
- Hash o firma para verificar integridad.
- Licencia y restricciones de uso.
- Política de datos y condiciones del proveedor.
- Resultados de evaluaciones de seguridad.
- Fecha de actualización o retiro previsto.
Un inventario tipo SBOM, ML-BOM o AI-BOM convierte dependencias invisibles en elementos gobernables.
4. Data and Model Poisoning: si la fuente cambia, la respuesta también
El envenenamiento ocurre cuando alguien altera datos de entrenamiento, ajuste, evaluación o embeddings para introducir errores, sesgos o comportamientos ocultos.
No siempre produce una falla evidente. Una puerta trasera puede permanecer inactiva durante las pruebas y aparecer únicamente ante una palabra o condición específica.
En un sistema RAG, el equivalente práctico puede ser más sencillo: se añade documentación falsa o desactualizada a la base de conocimiento y el modelo la utiliza como evidencia.
Los controles importantes son poco glamorosos:
- Procedencia documentada para cada fuente.
- Versionado de datasets, embeddings y modelos.
- Separación entre ingestión, evaluación y producción.
- Validación contra fuentes confiables.
- Detección de anomalías y cambios de comportamiento.
- Pruebas de regresión después de cada actualización.
Sin linaje, una respuesta incorrecta puede detectarse; explicar por qué apareció será mucho más difícil.
5. Improper Output Handling: la respuesta del modelo sigue siendo entrada no confiable
El modelo genera texto. El problema comienza cuando otra parte del sistema interpreta ese texto como una instrucción segura.
Si la salida se inserta directamente en HTML, SQL, una ruta de archivo o un comando, reaparecen vulnerabilidades conocidas: XSS, inyección SQL, escalamiento de privilegios o ejecución de código.
Por ejemplo, un asistente puede construir consultas a una base de datos usando lenguaje natural. Si el backend ejecuta el resultado sin parametrización, una respuesta inesperada puede convertirse en una operación destructiva.
La regla útil es tratar al modelo como a cualquier otra fuente no confiable:
- Validar tipos, esquemas y listas permitidas.
- Codificar la salida según el contexto donde se utilizará.
- Usar consultas parametrizadas.
- Evitar funciones abiertas como
execoeval. - Aislar cualquier ejecución de código generado.
- Aplicar reglas de negocio fuera del LLM.
6. Excessive Agency: funciones, permisos y autonomía excesivos
OWASP separa este problema en tres partes:
- Funcionalidad excesiva: el agente dispone de herramientas que no necesita.
- Permisos excesivos: la herramienta puede hacer más de lo requerido.
- Autonomía excesiva: las acciones sensibles no requieren aprobación.
Un asistente creado para resumir correos solo necesita lectura. Si la misma integración también puede enviar y eliminar mensajes, una inyección indirecta tiene mucho más espacio para causar daño.
La defensa correcta no consiste en pedirle al modelo que “tenga cuidado”. Consiste en reducir lo que técnicamente puede hacer:
- Una función específica en lugar de una herramienta abierta.
- Permisos de solo lectura cuando sean suficientes.
- Acciones ejecutadas con la identidad del usuario, no con una cuenta privilegiada genérica.
- Confirmación humana para pagos, envíos, publicaciones y eliminaciones.
- Autorización aplicada nuevamente en el sistema de destino.
7. System Prompt Leakage: ocultar el prompt no es seguridad
El prompt del sistema define el rol, tono y límites del asistente. Su filtración puede revelar reglas internas o información útil para preparar otros ataques.
La precisión importante de OWASP es esta: el system prompt no debe considerarse secreto ni utilizarse como control de seguridad.
Si allí aparecen una contraseña, token, cadena de conexión o regla de autorización, el problema principal no es que el prompt pueda filtrarse. El problema es que esa información fue almacenada en un lugar incorrecto.
Un diseño más seguro:
- Guarda secretos en un gestor especializado.
- Aplica autenticación y autorización fuera del modelo.
- Implementa reglas críticas con código determinista.
- Usa controles externos para revisar entradas, salidas y acciones.
- Supone desde el diseño que las instrucciones podrían conocerse.
El prompt orienta comportamiento. No debe decidir quién está autorizado a mover dinero, borrar datos o consultar expedientes.
8. Vector and Embedding Weaknesses: RAG necesita permisos, no solo similitud
RAG recupera fragmentos relevantes y los entrega al modelo como contexto. Si la búsqueda vectorial solo pregunta “¿qué texto se parece a esta consulta?” y no “¿qué texto puede ver esta persona?”, la aplicación puede filtrar información.
También puede recuperar contenido manipulado, mezclar fuentes contradictorias o utilizar embeddings de origen dudoso.
En ambientes con varias áreas o clientes, los metadatos de autorización deben viajar con cada fragmento:
- Organización o cliente propietario.
- Rol o grupo autorizado.
- Clasificación de sensibilidad.
- Documento, versión y fecha.
- Vigencia y fuente original.
La autorización debe aplicarse en cada recuperación. Haber iniciado sesión no garantiza que todos los resultados del vector store sean válidos para ese usuario.
9. Misinformation: una respuesta convincente puede seguir siendo falsa
Los LLM producen lenguaje plausible. No verifican automáticamente que cada afirmación sea verdadera.
OWASP relaciona este riesgo con alucinaciones, datos incompletos, sesgos y sobreconfianza del usuario. El daño aparece cuando una respuesta pasa directamente a una decisión, contrato, diagnóstico, cálculo o proceso.
OWASP cita el caso de un chatbot de Air Canada que ofreció información incorrecta sobre una tarifa por duelo. En Moffatt v. Air Canada, 2024 BCCRT 149, la empresa fue considerada responsable por la información publicada mediante su chatbot.
RAG puede mejorar el fundamento, pero necesita controles adicionales:
- Fuentes verificadas y vigentes.
- Citas que el usuario pueda abrir.
- Validación de fechas, valores y reglas críticas.
- Revisión humana proporcional al impacto.
- Una salida explícita de “no hay evidencia suficiente”.
- Pruebas con preguntas reales del negocio.
La responsabilidad no desaparece porque la frase haya sido generada por una IA.
10. Unbounded Consumption: cuando el costo y el uso no tienen techo
Cada inferencia consume capacidad y, muchas veces, dinero. Entradas enormes, solicitudes repetidas o tareas innecesariamente complejas pueden degradar el servicio y elevar la factura.
OWASP utiliza el término Denial of Wallet para describir ataques que agotan recursos financieros sin necesidad de derribar completamente la aplicación.
La protección necesita límites en varias capas:
- Solicitudes por usuario, IP, organización y clave.
- Tokens de entrada y salida.
- Concurrencia y duración de cada operación.
- Número de pasos y acciones de un agente.
- Presupuesto diario o mensual.
- Alertas por comportamiento anómalo.
- Degradación controlada bajo carga.
Una clave expuesta sin cuotas puede seguir funcionando mientras acumula un costo considerable. La disponibilidad y el presupuesto deben monitorearse juntos.
Cómo se encadenan los riesgos
Los diez puntos no viven aislados. Un incidente puede empezar en un documento y terminar en una herramienta corporativa.
| UN ATAQUE, EN UNA SOLA LÍNEA |
|---|
| Documento manipulado → RAG → LLM → herramienta con privilegios → información expuesta |
| Etapa | Qué sucede | Riesgo relacionado |
|---|---|---|
| Ingesta | Se indexa un archivo manipulado | LLM04 / LLM08 |
| Recuperación | RAG entrega la instrucción oculta al modelo | LLM01 / LLM08 |
| Decisión | El modelo interpreta el contenido como una orden | LLM01 |
| Acción | Una herramienta con permisos excesivos ejecuta la solicitud | LLM06 |
| Procesamiento | La aplicación confía en la salida sin validarla | LLM05 |
| Consecuencia | Información interna llega a un destino no autorizado | LLM02 |
Filtrar una frase maliciosa no rompe toda la cadena. Validar la ingestión, conservar permisos, limitar herramientas y aprobar acciones sí crea varias oportunidades para detenerla.
| LO MOLESTO |
|---|
| Un incidente serio no siempre necesita una vulnerabilidad espectacular. Puede construirse con cinco decisiones pequeñas que, por separado, parecían aceptables. |
Qué revisar antes de producción
| Pregunta | Evidencia mínima | Riesgos relacionados |
|---|---|---|
| ¿Qué datos puede conocer el sistema? | Inventario y clasificación | LLM02, LLM07, LLM08 |
| ¿De dónde vienen modelos y datos? | Procedencia, versiones y aprobaciones | LLM03, LLM04 |
| ¿RAG conserva los permisos de origen? | Pruebas entre usuarios y grupos | LLM02, LLM08 |
| ¿La salida se valida antes de utilizarse? | Esquemas, codificación y pruebas | LLM05 |
| ¿Qué acciones puede ejecutar el agente? | Lista de herramientas y permisos | LLM06 |
| ¿Qué operaciones requieren confirmación? | Flujo de aprobación documentado | LLM01, LLM06 |
| ¿Puede decir “no encontrado”? | Pruebas sin evidencia suficiente | LLM09 |
| ¿Existen límites técnicos y financieros? | Cuotas, presupuestos y alertas | LLM10 |
| ¿Se registran recuperaciones y acciones? | Logs protegidos y trazabilidad | Todos |
| ¿Se ejecutan pruebas adversariales y de regresión? | Casos, resultados y responsables | Todos |
La prueba de 60 segundos
Cuatro preguntas permiten detectar rápidamente dónde debería comenzar una revisión más profunda.
| Si la respuesta es “sí”... | El riesgo crece porque... | Revisa primero... |
|---|---|---|
| ¿La IA consulta documentos internos? | Puede recuperar contenido manipulado o no autorizado | Ingesta, procedencia y permisos RAG |
| ¿La IA puede llamar herramientas? | Una respuesta puede transformarse en una acción | Funciones, privilegios y aprobaciones |
| ¿La IA atiende a varios clientes o áreas? | Un error de separación puede filtrar información | Aislamiento, metadatos y autorización por consulta |
| ¿El uso genera costo por solicitud o token? | El abuso puede agotar presupuesto y capacidad | Cuotas, límites, alertas y presupuesto |
| SI RESPONDISTE “SÍ” A TRES O CUATRO |
|---|
| No significa que el sistema sea inseguro. Significa que ya no basta con evaluar el modelo: necesitas revisar la arquitectura completa y demostrar que los controles funcionan. |
Resumen
| Decisión | Impacto | Dificultad |
|---|---|---|
| Autorización fuera del LLM | Alto | Media |
| Mínimo privilegio para herramientas | Alto | Media |
| Procedencia y permisos en RAG | Alto | Media |
| Validación de salida | Alto | Baja–media |
| Límites de uso y presupuesto | Alto | Baja |
| Confiar únicamente en el prompt | Bajo | Baja |
La mayoría de los controles que más reducen el riesgo no pertenecen al modelo. Están en la arquitectura, los datos, los permisos y la operación.
Esa es la idea que conviene conservar del OWASP Top 10: la pregunta no es solamente qué tan bueno es el LLM, sino qué puede conocer, qué puede hacer y qué ocurre cuando se equivoca.
Fuentes oficiales
- OWASP GenAI Security Project
- OWASP Top 10 for LLM and GenAI Applications 2025
- LLM01:2025 Prompt Injection
- LLM02:2025 Sensitive Information Disclosure
- LLM03:2025 Supply Chain
- LLM04:2025 Data and Model Poisoning
- LLM05:2025 Improper Output Handling
- LLM06:2025 Excessive Agency
- LLM07:2025 System Prompt Leakage
- LLM08:2025 Vector and Embedding Weaknesses
- LLM09:2025 Misinformation
- LLM10:2025 Unbounded Consumption
- OWASP Application Security Verification Standard
- OWASP Top 10 for Agentic Applications 2026
Este contenido resume documentación técnica con fines informativos. La prioridad y severidad de cada riesgo deben evaluarse según los datos, las capacidades y el impacto real de cada sistema.