OWASP Top 10 para LLM, explicado.Los diez riesgos de las aplicaciones con modelos de lenguaje: cómo se explota cada uno, qué lo cierra y qué cambia cuando el modelo corre en tus propios servidores.

Directa, cuando el usuario escribe «olvida lo anterior y…», o indirecta, que es la peligrosa: la orden va escondida en un PDF, una web que lee el agente o un correo que resume el asistente, y el usuario ni la ve.

Nada del todo. Se limita el daño: contenido externo marcado como no fiable, permisos mínimos, autorización fuera del modelo y validación de la salida. Tiene sección propia más abajo.

En un asistente con RAG (el que busca en tu documentación antes de responder), las nóminas acaban en el mismo índice que la política de vacaciones y cualquiera puede preguntar por ellas.

Aplicar los permisos del usuario al recuperar los documentos, antes de que el texto llegue al modelo, indexar lo justo y revisar qué datos salen en respuestas y en logs.

Un modelo, unos pesos, una biblioteca de Python o un dataset de terceros llegan manipulados o con una licencia que no permite tu uso. Los pesos son ficheros enormes y opacos, así que nadie mira dentro.

Fuentes verificadas, versiones fijadas, hashes comprobados y formatos que no ejecutan código al cargarse (safetensors o GGUF en lugar de pickle).

Alguien cuela datos manipulados en el entrenamiento, el ajuste fino o los documentos del RAG y consigue sesgar respuestas o dejar una puerta trasera que se activa con una palabra concreta.

Saber de dónde viene cada documento, controlar quién puede añadir contenido al índice y repetir una batería de casos conocidos después de cada cambio.

El texto del modelo se pinta en una web, se ejecuta como consulta SQL o se usa como comando sin revisarlo. Es la inyección de siempre con un intermediario nuevo: XSS, inyección SQL o ejecución remota.

Tratar la salida del modelo como la entrada de un usuario cualquiera: validarla, escaparla y usar consultas parametrizadas.

Un agente con herramientas que tienen más permisos de los que necesita, o que encadena acciones sin que nadie las confirme. Con eso, una inyección pasa de respuesta rara a correo enviado, fichero borrado o pago hecho.

Mínimo privilegio por herramienta, autorización comprobada en el servicio que ejecuta la acción y confirmación humana para lo irreversible.

Conseguir que el modelo repita sus instrucciones es fácil. El problema es lo que algunos equipos meten en ellas: claves de API, nombres de servidores internos o reglas de negocio.

Dar por hecho que esas instrucciones acabarán publicadas, sacar de ellas los secretos y llevar las reglas importantes a controles que no dependan del modelo.

La base de datos vectorial del RAG no separa los datos de cada cliente, o deja insertar documentos a quien no debe, y la búsqueda devuelve lo que no toca o lo que un atacante ha preparado para salir.

Índices separados o filtro por permisos en cada consulta, escritura restringida y registro de qué fragmentos se usaron en cada respuesta.

El modelo se equivoca con mucha seguridad, inventa referencias o da por buenas cifras que no cuadran, y eso acaba en un informe o en la web sin que nadie lo revise.

Respuestas que citan su fuente, un asistente que se abstiene cuando no la encuentra y revisión humana en lo que se publica o se decide.

Un usuario malicioso o un bucle en un agente dispara la factura o tumba el servicio, y con muchas peticiones bien escogidas se puede llegar a copiar el comportamiento del modelo.

Cuotas por usuario, límites de tamaño de entrada y salida, tiempo máximo por petición y alertas cuando el consumo se sale de lo normal.